prevent vDos freeze
Moderators:daleadmin, Dale Harris, Alan, Andrew
I see trolling through some old posts there was a solution to fix screen freezes when using DosBox by changing the configuration from cycles=auto to cycles=high.
I am using VDos because of other issues I was having with DosBox but it is freezing when using receiving program. vDos doesn't seem to be able to modify its cpu settings. Has anyone got a solution?
Mine is a bit clumsy - use DoxBox when running the receiving program and vDos when running everything else.
Log
I am using VDos because of other issues I was having with DosBox but it is freezing when using receiving program. vDos doesn't seem to be able to modify its cpu settings. Has anyone got a solution?
Mine is a bit clumsy - use DoxBox when running the receiving program and vDos when running everything else.
Log
Re: prevent vDos freeze
I don't use the receive program, but just messing around in it doesn't get me any issues in DOSbox or vDOS
I'm willing to test some stuff and try and find a solution
Can you tell me specifically how you get this freeze (so i can recreate the problem for testing)
Also some info about your setup might be useful (e.g. what windows version, do you do anything over network etc)
I'm assuming you do have the latest version of vDos
Johann
I'm willing to test some stuff and try and find a solution
Can you tell me specifically how you get this freeze (so i can recreate the problem for testing)
Also some info about your setup might be useful (e.g. what windows version, do you do anything over network etc)
I'm assuming you do have the latest version of vDos
Johann
Re: prevent vDos freeze
Johann,
Maybe he is thinking about the freeze when one of my programs first starts under DOSBox.
Dale
Maybe he is thinking about the freeze when one of my programs first starts under DOSBox.
Dale
Re: prevent vDos freeze
Hi Dale,
Like i said, i can't recreate any freeze, in DOSbox as well in vDOS
But again, im just messing around in RECEIVE.EXE trying random stuff
I am not using RECEIVE.EXE personally and i'm not even fully sure what it does/is supposed to do (i do have a general idea)
So unless i can get some info on how to recreate this issue myself, there's nothing much i can do
I can say this; although vDOS is a fork of DOSbox, you can NOT change CPU/CYCLES in vDOS
There is another version called vDOS-plus, which is based on vDOS and DOSbox that has more features than vDOS, however i never used vDOS-plus
As far as i can see right now appearantly RECEIVE.EXE is working in both DOSbox and vDOS(current latest versions), although i can not guarantee anything until i know what i'm doing in there
Like i said, i can't recreate any freeze, in DOSbox as well in vDOS
But again, im just messing around in RECEIVE.EXE trying random stuff
I am not using RECEIVE.EXE personally and i'm not even fully sure what it does/is supposed to do (i do have a general idea)
So unless i can get some info on how to recreate this issue myself, there's nothing much i can do
I can say this; although vDOS is a fork of DOSbox, you can NOT change CPU/CYCLES in vDOS
There is another version called vDOS-plus, which is based on vDOS and DOSbox that has more features than vDOS, however i never used vDOS-plus
As far as i can see right now appearantly RECEIVE.EXE is working in both DOSbox and vDOS(current latest versions), although i can not guarantee anything until i know what i'm doing in there
Re: prevent vDos freeze
Hi Johann,
I was looking at using the receiving program to move stock from one shop to a second one we are in the process of opening - so I have never used it before. My work around is ok so don't spend too much time on it.
I have done a bit of playing - I can run the "RECEIVE" program directly from vDOS.
It is just that on the windows 10 laptop we use as the back office and testing machine, I use vDOS 100% for POS and nothing else. So my autoexec is set up to go straight into POS.
USE C: c:\pos
APRINT6
POS
When trying to run the "RECEIVE" program from File Maintenance and then "POSCONFG" it hangs when I hit <enter> on the 'Welcome to the Pos Receiving' page.
Like I said not a biggie, as the work around is simple.
Log
I was looking at using the receiving program to move stock from one shop to a second one we are in the process of opening - so I have never used it before. My work around is ok so don't spend too much time on it.
I have done a bit of playing - I can run the "RECEIVE" program directly from vDOS.
It is just that on the windows 10 laptop we use as the back office and testing machine, I use vDOS 100% for POS and nothing else. So my autoexec is set up to go straight into POS.
USE C: c:\pos
APRINT6
POS
When trying to run the "RECEIVE" program from File Maintenance and then "POSCONFG" it hangs when I hit <enter> on the 'Welcome to the Pos Receiving' page.
Like I said not a biggie, as the work around is simple.
Log
Re: prevent vDos freeze
Hey biglog,
First of all, i don't mind spending some time on it at all, also i feel kind of involved when it comes to issues with POS in emulators so i actually like investigating and possibly solving such issues.
It's still not completely clear to me what you are trying to do but i've tried the following:
Im running Windows 10 64bit here with vPOS, using autoexec or not is really not important as long as you've got everything mounted right you should be good to go
So at the DOS prompt i ran RECEIVE.EXE to create a file with some items that i want to inject into my stock table
I saved it using F3 and exited the program
Then i opened POS.EXE at the prompt, went to file maintenance and selected (8)Read Receiving File
I selected the .RCV file created in step one, followed onscreen instructions and my items got properly added
I must however say that i skipped backing up my stock table, since using this option crashed my POS
First of all, i don't mind spending some time on it at all, also i feel kind of involved when it comes to issues with POS in emulators so i actually like investigating and possibly solving such issues.
It's still not completely clear to me what you are trying to do but i've tried the following:
Im running Windows 10 64bit here with vPOS, using autoexec or not is really not important as long as you've got everything mounted right you should be good to go
So at the DOS prompt i ran RECEIVE.EXE to create a file with some items that i want to inject into my stock table
I saved it using F3 and exited the program
Then i opened POS.EXE at the prompt, went to file maintenance and selected (8)Read Receiving File
I selected the .RCV file created in step one, followed onscreen instructions and my items got properly added
I must however say that i skipped backing up my stock table, since using this option crashed my POS
Re: prevent vDos freeze
Once POS is running, from the main screen I select;
3. File Maintenance
then
1. Run POSCONFG
then press any key
Select - Receiving
then
1. Run receiving program now
then press any key
Press <ENTER> to start
then press any key to continue
This is were it freezes and vDOS goes from using about 0.4% CPU load to 34% (looking at Task Manager)
regards
Log
3. File Maintenance
then
1. Run POSCONFG
then press any key
Select - Receiving
then
1. Run receiving program now
then press any key
Press <ENTER> to start
then press any key to continue
This is were it freezes and vDOS goes from using about 0.4% CPU load to 34% (looking at Task Manager)
regards
Log
Re: prevent vDos freeze
Biglog,
Recreating your steps as described above, i experience the following:
I can start the receive program but i indeed get a huge CPU usage spike from almost 0,6%-1,5% to 58%
Indeed results in a 'short freeze' (or delay) during the final notice prior to the receive menu (the "You must remember that ...etc Press any key")
After a second or two/three i press the "any-key" ;-) and the program functions as normal
I'm running Windows 10 64bit on a AMD Athlon II P320 Dual-Core processor @2.10GHz with 4GB RAM
I will try again on a second lower spec 32bit computer, but at this moment it's in storage
Have you tried raising the process priority of vDOS in taskmanager?
[EDIT]
Funny thing:
I just did the same procedure on this machine but now using DOSbox
I still got some CPU spike, but much lower than vDOS (approx 32%) and expierence no temporary delay during last notification before receive menu
Recreating your steps as described above, i experience the following:
I can start the receive program but i indeed get a huge CPU usage spike from almost 0,6%-1,5% to 58%
Indeed results in a 'short freeze' (or delay) during the final notice prior to the receive menu (the "You must remember that ...etc Press any key")
After a second or two/three i press the "any-key" ;-) and the program functions as normal
I'm running Windows 10 64bit on a AMD Athlon II P320 Dual-Core processor @2.10GHz with 4GB RAM
I will try again on a second lower spec 32bit computer, but at this moment it's in storage
Have you tried raising the process priority of vDOS in taskmanager?
[EDIT]
Funny thing:
I just did the same procedure on this machine but now using DOSbox
I still got some CPU spike, but much lower than vDOS (approx 32%) and expierence no temporary delay during last notification before receive menu
Re: prevent vDos freeze
Hi Johann,
My Specs are:
Windows 10 64 bit
Intel i7-5500U @ 2.4GHz
8GB RAM
The process priority defaults back to normal each time I restart vDOS.
I tried at High and Real Time with no change on what I was getting previously.
Post Script
AGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHH
Fixed it - I thought I had the latest version of vDOS, but no. I downloaded the current version and installed.
Now I have the same result as you - quite a lag before starting the Receiving program - but it does start.
Thanks for the prodding - I know it was in your first reply.
Log
My Specs are:
Windows 10 64 bit
Intel i7-5500U @ 2.4GHz
8GB RAM
The process priority defaults back to normal each time I restart vDOS.
I tried at High and Real Time with no change on what I was getting previously.
Post Script
AGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHH
Fixed it - I thought I had the latest version of vDOS, but no. I downloaded the current version and installed.
Now I have the same result as you - quite a lag before starting the Receiving program - but it does start.
Thanks for the prodding - I know it was in your first reply.
Log
Re: prevent vDos freeze
Would a 64 bit version of the "Receive" program be helpful?
You would not be able to launch it from the POSCONFG.EXE program, you would have to run it directly.
Dale
You would not be able to launch it from the POSCONFG.EXE program, you would have to run it directly.
Dale
Re: prevent vDos freeze
Great news biglog!
No problem at all, i'm glad we got the issue sorted out
Hi Dale,
If you are asking "Would it be better to make 64-bit versions of all my software so it wouldn't rely on possibly shoddy coded 3rd party software combined with any workaround software to function but instead would run natively on 64-bit systems?" then i think the answer should be quite obvious.
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
In this current situation i think the answer should be no and just complicate things even more, e.g.:
Creating another workaround (a new 'external' RECEIVE that wouldn't be accessible through POSCONFG) instead of just upgrading your platform (in this case DOSbox and/or vDOS) to the most recent revised version.
Just imagine how you'd have to expand your instruction manual on your site:
"Note that if you are using a 64 bit system you might run in to issues with the receive function but to use it correctly you can download this alternative receive program. To use this correctly....blah...blah...etc)"
or just:
"If you run my software in any emulator such as DOSbox (or vDOS) always make sure you use the latest version of that emulator before reporting any issues"
![Laughing :lol:](./images/smilies/icon_lol.gif)
To stray more offtopic for once i do have these two suggestions:
-On your website i would stop suggesting the use of DOSbox but if you must suggest anything, suggest using vDOS instead but in any case stress the importance of using the latest available versions
-Second, however this is responsibility of the end-user, the combo of using your software with any emulator can move into a grey area quickly when it comes to license agreements of any 3rd party software used.
Technically i think this is commercial use mostly and that's possibly not fully supported for free use in those freeware/GNU GPL/etc licenses.
Therefore it would be good practice to move away from relying on other 3rd party 'free' softwares to make use of DHPOS.
Just my two cents
![Wink ;)](./images/smilies/icon_wink.gif)
Johann
Re: prevent vDos freeze
Johann,
Since all of the program files would have to be upgraded to QB64 to have a 64 bit version I would have to upgrade the RECEIVE.EXE program eventually. I have already upgraded some of them. So the only options are either now or later. May as well be now.
Until the entire 64 bit version lands I continue to promote DOSBox because it does work and there are a whole pile of current DHPOS users that use it. Sort of an installed base as it were.
But if someone wants to run off in another direction like vDOS, if it works for them that is fine with me. The more options the better.
Dale
Since all of the program files would have to be upgraded to QB64 to have a 64 bit version I would have to upgrade the RECEIVE.EXE program eventually. I have already upgraded some of them. So the only options are either now or later. May as well be now.
Until the entire 64 bit version lands I continue to promote DOSBox because it does work and there are a whole pile of current DHPOS users that use it. Sort of an installed base as it were.
But if someone wants to run off in another direction like vDOS, if it works for them that is fine with me. The more options the better.
Dale
Re: prevent vDos freeze
I have created a 64 bit version of the Receive / Inventory program and you can download it from here http://keyhut.com/qb64.htm
The file there contains all of the finished 64 bit program files.
Please note in the instructions posted on the link that you will not be able to access these programs from POSCONFG.EXE.
Also note that since you do not use a DOS emulator with these new files you do not have to MOUNT multiple drives to copy files.
Dale
The file there contains all of the finished 64 bit program files.
Please note in the instructions posted on the link that you will not be able to access these programs from POSCONFG.EXE.
Also note that since you do not use a DOS emulator with these new files you do not have to MOUNT multiple drives to copy files.
Dale
Who is online
Users browsing this forum: No registered users and 215 guests