Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Michael, Eric, Dave I just altered my EMail setup to better track this thread. I have missed some messages. On Fri, Aug 17, 2012 at 9:30 AM, Michael B. Brutman mbbrut...@brutman.comwrote: John, Just to make sure I understand ... You are running a batch file that is doing net use to setup printer shares, a file share, and loads nansi.sys. And the output to the screen during that time is around 8.5 chars per second? Just as a comparison, running the FreeDOS Beta of 1.1 under VirtualBox I can go to c:\fdos\doc\mtcp and execute type ftpsrv.txt. The entire time to watch that 37KB file scroll by is around 7 seconds, or about 5200 chars per second including the scrolling time. (The time to scroll is longer than the time to print chars.) Is VirtualBox slow because of what you are doing in those batch files, or is it slow no matter what you do? For example, try my little test there and see how fast it goes. We need to isolate what is causing your slowdown. And please try this with both TSRs and device drivers loaded and without so that we can see if it is a TSR or device driver problem. I have never heard of something that slow before in VirtualBox. As an alternative, you can try VMWare to see if it is something specific to VirtualBox. (I have found problems in VirtualBox before related to programs that reprogram the programmable interrupt timer. The mTCP PING program exposed it. It only affected PING while it was running.) RAM should not be the issue. But laptop hardware tends to throttle the speed if it is not plugged into the wall and allowed to run at full speed. I doubt this is your problem, but just in case, please clarify that the laptops are on wall power and are set to run at maximum CPU speed while on wall power. FDAPM and APMDOS are only introduced as a way to conserve battery power or reduce electricity consumption when used with wall power. Which reduces heat, which is always a good thing ... mTCP requires its own network adapter and can not co-exist with MS-Client. The same is true for WATTCP based applications. If you are trying to use both the MS-Client and mTCP or WATTCP programs at the same time on the same adapter then you need to add another adapter. Each of those programs assumes that they own the adapter and will fight each other in fun ways. Mike -- Cheers John S Wolter LinkedIn: johnswolter http://www.linkedin.com/in/johnswolter - Mailto:johnswol...@wolterworks.com - Desk: 734-408-1263 - USA, Eastern Standard Time, -5 GMT, -4 GMT DST -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
it is my sincere belief that everyone possible should file a feature request/bug report with the virtualbox people so UIDE works without the two-minute analogy delay upon v.m. boot, including those who know why and how UIDE is delayed. if we do this sincerely then they probably will be happy to accomodate us in future sincerely. eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
John, I'll let Mike and others respond about the details of MS-Client - you should note, however, that MS-Client is not FreeDOS software - it is Microsoft software. If I understand you correctly you are using networking only for the purpose of accessing a printer on the host computer. If this is true I would recommend using VMWare player and creating an LPT port for your DOS application to use. (I don't think that this can be done in VirtualBox) Then on the host Windows machine use NET USE or some other sort of mapping technique to map LPT1 to the appropriate network printer. Of course you will then get the usual problems with running a new printer with old DOS programs. Do you have a DOS compatible printer? If all you are doing with networking is printing on your local PC, I would get rid of MS Client as well as the power management utitlities and see how your application works. For accessing drives I would again use VMWare and the excellent VMSMOUNT.EXE program which will allow your DOS system to access any directory on the Windows host - again without using networking software in DOS. Dave -Original Message- From: john s wolter johnswol...@wolterworks.com To: Michael B. Brutman mbbrut...@brutman.com Cc: Discussion and general questions about FreeDOS. freedos-user@lists.sourceforge.net Sent: Thu, Aug 16, 2012 9:05 pm Subject: Re: [Freedos-user] FreeDos in VirtualBox not a sure thing Mike, Good to make your acquaintance. Let me respond to your questions and remarks below. On Thu, Aug 16, 2012 at 12:23 AM, Michael B. Brutman mbbrut...@brutman.com wrote: John, Maybe you could help us by being very specific with what worked and what went wrong? The only thing I could gather from your message was that it was difficult to do, and it was slow. I took a moment to get a specific speed measure. It is an extended ASC-II set display application. Inside the VM I run an application batch file which among other items like NET USEng a printer loads DEVLOADs NANSI.SYS. Since the initial display is going at a slow rate I used a stopwatch to estimate the time to display the first 40 characters. They are the upper border line using 40 characters ' * ' . It took 4.7 seconds for those 40 characters to be displayed. That is 8.5 characters per second written to the screen. That screen has a simple one column bar-menu that uses the up-down arrows. Each entry of a up or down arrow has a lag to it. I rate that as slow. One thing that is essential for good performance is to ensure that your host machine is new enough to support the virtual processor extensions in the CPU. If it does not, then the virtual machine gets emulated one instruction at a time. This is orders of magnitude slower than if you can use the virtual processor extensions. My 3 year old Intel i5 Quad Core chip is fine, but modern Atom processors do not have the extensions. Any virtual machine (FreeDOS or otherwise) will be painful without them. It sounds like your machine has the processor extensions, but you need to ensure they are enabled in the BIOS. Both the development and target are i5 Laptops with 6-8 GB RAMM. Those are the most important performance spec. The VT features are turned on. I have turned it off without any noticeable difference in performance. Even if you do not use the power saving TSRs or programs that are power aware, the worst that will happen is that the virtual machine running FreeDOS will use one of the host CPU cores. For a desktop system this is not a major problem. On a laptop it will shorten battery life. You have a wide variety of TSRs to choose from - FDAPM and DOSIDLE are my favorites so far. I'm using the power saving FDAPM and APMDOS.. Why are the power saving utilities are playing a role is a question? FreeDOS's NANSI.SYS is used as it is required to see anything on the display. SHARE is being loaded. CIFS/SMB issues: ...Loading... PROTOCOL.INI SHARE netbind tcptsr tinyrfc nmtsr emsbfr NET CONFIG gives the default freeDOS computer and user information. The NET VIEW gives the host but will not give information for the host attached printer. I am able to NET USE LPT1: \\... to assign it. I had altered the workgroup to the host's local workgroup. NT or Acitve Directory Domains are NOT used. Simple workgroup networking is active. It keeps asking for an ID and password for the printer. I provide the same as I do signing on to the computer itself. I have not yet seen a way to administer passwords for the directories or printers shared by the host. It seems to get the ID but tells me the password does not match the printer's password. Microsoft has done a great job of obscuring things. One point of confusion is the setup of mTCP vs MS-Client. It is not clear how independent these are of each other. Can one have a static IP while the other gets a dynamic, DHCP? I have just found
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
John, Just to make sure I understand ... You are running a batch file that is doing net use to setup printer shares, a file share, and loads nansi.sys. And the output to the screen during that time is around 8.5 chars per second? Just as a comparison, running the FreeDOS Beta of 1.1 under VirtualBox I can go to c:\fdos\doc\mtcp and execute type ftpsrv.txt. The entire time to watch that 37KB file scroll by is around 7 seconds, or about 5200 chars per second including the scrolling time. (The time to scroll is longer than the time to print chars.) Is VirtualBox slow because of what you are doing in those batch files, or is it slow no matter what you do? For example, try my little test there and see how fast it goes. We need to isolate what is causing your slowdown. And please try this with both TSRs and device drivers loaded and without so that we can see if it is a TSR or device driver problem. I have never heard of something that slow before in VirtualBox. As an alternative, you can try VMWare to see if it is something specific to VirtualBox. (I have found problems in VirtualBox before related to programs that reprogram the programmable interrupt timer. The mTCP PING program exposed it. It only affected PING while it was running.) RAM should not be the issue. But laptop hardware tends to throttle the speed if it is not plugged into the wall and allowed to run at full speed. I doubt this is your problem, but just in case, please clarify that the laptops are on wall power and are set to run at maximum CPU speed while on wall power. FDAPM and APMDOS are only introduced as a way to conserve battery power or reduce electricity consumption when used with wall power. Which reduces heat, which is always a good thing ... mTCP requires its own network adapter and can not co-exist with MS-Client. The same is true for WATTCP based applications. If you are trying to use both the MS-Client and mTCP or WATTCP programs at the same time on the same adapter then you need to add another adapter. Each of those programs assumes that they own the adapter and will fight each other in fun ways. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Hi! Two thoughts about NANSI being slow in VirtualBox while network drives and printers are used and FDAPM is active: In DOSEMU, you can configure how agressive screen updates should be. So it can try to keep up with screen updates, or it can just occasionally do a window update. DOSEMU also runs DOS in a window in Linux, so it is similar to a VM, but differs in not emulating the CPU. It just emulates keyboard, screen and similar hardware for DOS :-) If you tell DOSEMU to only update the window 10 or 20 times per second, you get a nice user experience at little CPU load. The second thought is that network printers / drives combined with your other software (NANSI probably is no interesting factor here, but you can try NNANSi, or try other command line options for NANSI first?) and FDAPM might get FDAPM to try to save too much of your CPU load, so you save a lot of energy but get a sluggish, unpleasand user experience. Read the FDAPM documentation for alternative command line options, e.g. the ADV: style ones, to make it more cautious. Note that not loading any FDAPM style software can be another option, but depending on your VM, could lead to permanently high CPU load. You can try to use other software like DOSIDLE or try the FreeDOS kernel (config.sys) IDLEHALT option, which acts a bit like a FDAPM lite, saving energy mostly when waiting for keyboard input only :-) Sometimes the VM itself also has options to save energy or limit the amount of CPU time available to DOS. In plain real hardware, FDAPM SPEED options can be used to activate ACPI throttle. That freezes your CPU for each N out of 8 time slices (of e.g. 1/32000 sec). While being much less elegant than modern ways to lower the complete CPU clock and voltage, it gives at least SOME way to forcibly limit CPU usage :-) Note that low speeds below 4 can feel jerkish... Regards, Eric -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Op 16-8-2012 0:46, john s wolter schreef: I spent four days getting FreeDOS to work as a guest OS inside a VirtualBox machine. The path to success was a rocky and time consuming trial and error process. Once the particular console program was running it was not very fast. The customer deemed it to be usable. http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox is a general guide, it's not as network-specific though as http://lazybrowndog.net/freedos/virtualbox/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Hi Cordata,
So is the problem simply eating up processor time?
Note that this is probably not VM specific and would
also happen on real hardware. Why not run DOS on your
real 64 bit CPU? At boot, it is in 16 bit addr space
anyway, allowing the usual DOS 16/32 bit calculations.
You would waste the extra CPU cores and ability to do
things with more than 4 GB RAM or 64 bit calculations
(unless using the FPU) but running DOS inside a VM in
another OS will have the same problem. Of course it is
good to run DOS inside a VM if you want to use a host
OS (Linux, Windows) while just ALSO running some DOS
things in the VM. Also, the VM can help by behaving as
if it had classic sound / graphics / network cards, so
DOS does not have to use HDA / accel graphics / Wifi /
USB / other drivers itself :-)
But the real problem is the applications. For example FreeDOS
EDIT.EXE is a terrible offender. I modified it for my own use to
throw in a few HLTs and now it works great. People will talk about
making applications FDAPM aware and...
Note that EDIT already WAS working great with FDAPM for
example in version 0.7d, but something in some of the
newer versions broke that :-( Applications which just
use blocking keyboard reads are already fine anyway, so
only applications like EDIT or SSH2DOS which do other
things in the background need to explicitly take care
to have FDAPM-detectable idle states.
Here is the relevant code from EDIT 0.7d to help FDAPM:
BOOL dispatch_message(void)
{
...
/* only message.c can fill the event queue, but all components */
/* can fill the message queue. Events come from user or clock. */
if ( (EventQueueCtr == 0) (MsgQueueCtr == 0)
(handshaking == 0) ) { /* BORED - new 0.7c */
union REGS r;
r.h.ah = 0x84; /* network idle call */
int86(0x2a, r, r);/* network interfaces */
}
...
... process events in the queue ...
...
}
If you have the source code, this should be easy. ...
look for processor loops and put in some HLTs.
Because EDIT has a message pump, it was less easy there.
On the other hand, as said, most DOS apps poll for user
input at some point, usually when they have time to do
things for the user, in other words, when they are idle.
As long as that polling is blocking (wait for key!) and
not busy waiting (key pressed? no? then check again at
once!) it is easy enough for FDAPM in APMDOS mode to get
your CPU usage down by doing some HLT and similar for you.
For comparison, EDIT also has non-user events which have
to get pumped through the message pump, so if you were to
just use blocking wait for input, the clock and maybe a
screen update here and there would freeze while the user
is not typing (or clicking, EDIT has mouse...) anything.
In SSH2DOS, for example, the problem is that it always is
keeping an eye on the network to see whether there is any
new data to display, which makes your CPU go to 100%. If
it had some concept of now I have looked often enough in
the incoming network data buffer for this second, and a
buffer which can block when it gets full, it would help.
Regards, Eric
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Hi Eric, Note that this is probably not VM specific and wouldalso happen on real hardware. If I'm running DOS in a production environment on real hardware I (personally) would make sure the hardware could handle it and not overheat. There are plenty of industrial solutions out there that will do this. So I do think this issue applies more to VMs. In SSH2DOS, for example, the problem is that it always iskeeping an eye on the network to see whether there is anynew data to display, which makes your CPU go to 100%. Ifit had some concept of now I have looked often enough inthe incoming network data buffer for this second, and abuffer which can block when it gets full, it would help.Regards, Eric Note that SSH2DOS uses WATTCP. WATTCP already includes a yield function which can be used to provide for multitasking which in this case is a HLT. Simply write a small function that does nothing but HLT, then set the WATTCP yield function to point there, then recompile... I have had success with this method on the old WATTCP FTP client. Maybe if I ever get the time this could be a good contribution for me to make... (since I think it's so easy and all that.. :-) Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] FreeDos in VirtualBox not a sure thing
I spent four days getting FreeDOS to work as a guest OS inside a VirtualBox machine. The path to success was a rocky and time consuming trial and error process. Once the particular console program was running it was not very fast. The customer deemed it to be usable. Later in the day the customer cancelled a small DOS software install in preference to a larger native Windows 7 development. The customer had decided to purchase an older computer to run the DOS application from hard disk. It amounts to a lost increment of business for myself that is not significant. This situation indicates to me that efficient execution of FreeDOS in Virtual Machines must be made to be transparently easy. VMs are a way to make FreeDOS available as 16-bit support withers away. The industry leader's 64-bit OS does not support 16-bit DOS programs directly as in prior versions. Open source software developers, unfairly, have more pressures on them to prove the results. I've seen the form discussions as do others about run-away keyboard polling and other such issues. Solving these nagging issues may not look to be glamorous but can swing perceptions of FreeDOS substantially. There are commercial utilities claiming to control problems but I ask are there equivalent features or settings within FreeDOS? FreeDOS did not create these wild-hare programs but is being painted with their behaviors. It is FreeDOS's burden in life:(i. The tweaking of the FreeDOS VM with networking in VirtualBox...0 GeneralBasic: OS = Other, Version = DOS SystemMotherboard: 32 MB, Chipset PIIX3, ...Processor: Cap 87% ...Acceleration: uncheck Enable VT-x/AMD-V Storage: IDE Controller, FreeDOS...vdi image NetworkAdapter 1: Enabled, Host-only Adapter, Name=VirtualBox Host-Only Ethernet Adapter USB: Enabled for 1.1, Addon Extensions not used The virtual machine network adapter choice was the 'VirtualBox host-only Ethernet adapter'. I used that to establish a CIFS/SMB LPT1: printer redirection to the host's, Windows 7, USB attached HP C4400 printer. The computer is an HP laptop with i5 CPU with 8 GB of RAMM. If there is a list of well-known issues, I would like to see if an altered configuration would help performance. I have taken a few minutes to install DOSBox which seemed fairly snappy. I have yet to try the customer's program. I'll be giving that a try. Cheers John S Wolter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
Can you describe what exactly were the problems?
As for myself I've had no issues with getting FreeDOS to run in VMWare player,
QEMU and VitualBox. I used the original FreeDOS 1.0 install and have manually
updated the kernel since then. As for VirtualBox specifically, it will run a
VMDK file so I use the same VMDK file that I have created for VMWare - no
problems. For daily use I use VMWare under Windows XP, under Linux I use QEMU
and sometimes use QEMU under Windows in special situations. I almost never use
VirtualBox but fired it up just now after your posting.
So is the problem simply eating up processor time?
FreeDOS from an OS point of view is actually pretty good - there is an option
in the kernel to HLT during waits for keyboard input (IDLEHALT=-1 in
FDCONFIG.SYS) which I have used and recommend.
But the real problem is the applications. For example FreeDOS EDIT.EXE is a
terrible offender. I modified it for my own use to throw in a few HLTs and now
it works great. People will talk about making applications FDAPM aware and
using the mutliplex interrupt - I personally don't do these things - I make
sure that the application in question is doing a HLT frequently. (For those
who think the computer will lock up the HLT directive halts the processor until
the next interrupt... not forever)
So you must customize every application the user will touch.
If you have the source code, this should be easy. .. look for processor loops
and put in some HLTs.
If you don't have the source code you are going to have to run thru a debugger
and find where the program is looping ... break the debugger when windows says
you're at 100% utilization, should be easy to figure out. Then you need to
patch the BIOS routine, DOS routine or do a binary patch to the application.
Basically we have no idea what kind of loop or polling your application might
do. There is no guarantee that
your app is calling the OS or BIOS on these loops so the operating system will
not be able to fix your problems.
Here's an example:
Original program:
while (hw_not_ready)
{
int hw_status = read_hw(); /* read_hw could be anything, like inportb() */
if (hw_status == GOOD) hw_not_ready=FALSE;
}
Better program for a VM:
while (hw_not_ready)
{
int hw_status=read_hw();
if (hw_status==GOOD) hw_not_ready=FALSE;
else delay_a_tick();
}
bios_clk_ptr = MK_FP(0,0x46c);
void delay_a_tick()
{
long ticks = *bios_clk_ptr;
while(*bios_clk_ptr == ticks)
_asm hlt;
}
-Original Message-
From: john s wolter johnswol...@wolterworks.com
To: freedos-user freedos-user@lists.sourceforge.net
Sent: Wed, Aug 15, 2012 5:47 pm
Subject: [Freedos-user] FreeDos in VirtualBox not a sure thing
I spent four days getting FreeDOS to work as a guest OS inside a VirtualBox
machine. The path to success was a rocky and time consuming trial and error
process. Once the particular console program was running it was not very fast.
The customer deemed it to be usable.
Later in the day the customer cancelled a small DOS software install in
preference to a larger native Windows 7 development. The customer had decided
to purchase an older computer to run the DOS application from hard disk. It
amounts to a lost increment of business for myself that is not significant.
This situation indicates to me that efficient execution of FreeDOS in Virtual
Machines must be made to be transparently easy. VMs are a way to make FreeDOS
available as 16-bit support withers away. The industry leader's 64-bit OS does
not support 16-bit DOS programs directly as in prior versions. Open source
software developers, unfairly, have more pressures on them to prove the
results.
I've seen the form discussions as do others about run-away keyboard polling and
other such issues. Solving these nagging issues may not look to be glamorous
but can swing perceptions of FreeDOS substantially. There are commercial
utilities claiming to control problems but I ask are there equivalent features
or settings within FreeDOS?
FreeDOS did not create these wild-hare programs but is being painted with their
behaviors. It is FreeDOS's burden in life:(i.
The tweaking of the FreeDOS VM with networking in VirtualBox...0
GeneralBasic: OS = Other, Version = DOS
SystemMotherboard: 32 MB, Chipset PIIX3,
...Processor: Cap 87%
...Acceleration: uncheck Enable VT-x/AMD-V
Storage: IDE Controller, FreeDOS...vdi image
NetworkAdapter 1: Enabled, Host-only Adapter, Name=VirtualBox Host-Only
Ethernet Adapter
USB: Enabled for 1.1, Addon Extensions not used
The virtual machine network adapter choice was the 'VirtualBox host-only
Ethernet adapter'. I used that to establish a CIFS/SMB LPT1: printer
redirection to the host's, Windows 7, USB attached HP C4400 printer. The
computer is an HP laptop with i5 CPU with 8 GB of RAMM.
If there is a list of well-known issues, I would like to see if an altered
configuration would help performance.
I have taken
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
No Name,
Are you one of the developers?
Can you describe what exactly were the problems?
No. It is not clear if the issue is within FreeDOS, the applications
program, the VM, or VirtualBox itself. It is good that FreeDOS and
VirtualBox have source code. The applications program does not.
As for myself I've had no issues with getting FreeDOS to run in VMWare
player, QEMU and VitualBox. I used the original FreeDOS 1.0 install and
have manually updated the kernel since then.
Here is the page I used as a starting point.
http://lazybrowndog.net/freedos/virtualbox/ The iso provided has a
configuration and FreeDOS setup. I believe is uses the 1.1 disk.
I used Host-Only Ethernet adapter instead of the bridge adapter for this
local application program. This usually makes sense for local installs
that are not using network features. Selection #4 is what was needed. I
used that after using other cookbook only solutions did not work.
As for VirtualBox specifically, it will run a VMDK file so I use the same
VMDK file that I have created for VMWare - no problems. For daily use I
use VMWare under Windows XP, under Linux I use QEMU and sometimes use QEMU
under Windows in special situations. I almost never use VirtualBox but
fired it up just now after your posting.
It appears you do not use VirtualBox, preferring QEMU and VMware.
VirtualBox is not in the top three.
So is the problem simply eating up processor time?
Good question.
FreeDOS from an OS point of view is actually pretty good - there is an
option in the kernel to HLT during waits for keyboard input (IDLEHALT=-1 in
FDCONFIG.SYS) which I have used and recommend.
I've not found that in the manual. Let me know where those are documented
But the real problem is the applications. For example FreeDOS EDIT.EXE is
a terrible offender. I modified it for my own use to throw in a few HLTs
and now it works great. People will talk about making applications FDAPM
aware and using the mutliplex interrupt - I personally don't do these
things - I make sure that the application in question is doing a HLT
frequently. (For those who think the computer will lock up the HLT
directive halts the processor until the next interrupt... not forever)
Yes, I called them wild-hare programs. My point is that even though
FreeDOS is not cause of the issues it is time to add some ways for it track
to the executions and keep things under control. A keyboard port should be
controlable.
So you must customize every application the user will touch.
If you have the source code, this should be easy. .. look for processor
loops and put in some HLTs.
If you don't have the source code you are going to have to run thru a
debugger and find where the program is looping ... break the debugger when
windows says you're at 100% utilization, should be easy to figure out. Then
you need to patch the BIOS routine, DOS routine or do a binary patch to the
application.
Basically we have no idea what kind of loop or polling your application
might do. There is no guarantee that
your app is calling the OS or BIOS on these loops so the operating system
will not be able to fix your problems.
Here's an example:
I see it will have to read the code. I wonder if a Sleep or Napping
function is a better approach. This might be an event awakened when the
subscribed service asks for service with a callback. HLT, halts the
processor as you pointed out. The subscribed service can be adjusted in
sitsu to get the desired level of attention for say the keyboard.
Original program:
while (hw_not_ready)
{
int hw_status = read_hw(); /* read_hw could be anything, like inportb()
*/
if (hw_status == GOOD) hw_not_ready=FALSE;
}
Better program for a VM:
while (hw_not_ready)
{
int hw_status=read_hw();
if (hw_status==GOOD) hw_not_ready=FALSE;
else delay_a_tick();
}
bios_clk_ptr = MK_FP(0,0x46c);
void delay_a_tick()
{
long ticks = *bios_clk_ptr;
while(*bios_clk_ptr == ticks)
_asm hlt;
}
-Original Message-
From: john s wolter johnswol...@wolterworks.com
To: freedos-user freedos-user@lists.sourceforge.net
Sent: Wed, Aug 15, 2012 5:47 pm
Subject: [Freedos-user] FreeDos in VirtualBox not a sure thing
I spent four days getting FreeDOS to work as a guest OS inside a
VirtualBox machine. The path to success was a rocky and time consuming
trial and error process. Once the particular console program was running
it was not very fast. The customer deemed it to be usable.
Later in the day the customer cancelled a small DOS software install in
preference to a larger native Windows 7 development. The customer had
decided to purchase an older computer to run the DOS application from hard
disk. It amounts to a lost increment of business for myself that is not
significant.
This situation indicates to me that efficient execution of FreeDOS in
Virtual Machines must be made to be transparently easy. VMs are a way
Re: [Freedos-user] FreeDos in VirtualBox not a sure thing
John, Maybe you could help us by being very specific with what worked and what went wrong? The only thing I could gather from your message was that it was difficult to do, and it was slow. One thing that is essential for good performance is to ensure that your host machine is new enough to support the virtual processor extensions in the CPU. If it does not, then the virtual machine gets emulated one instruction at a time. This is orders of magnitude slower than if you can use the virtual processor extensions. My 3 year old Intel i5 Quad Core chip is fine, but modern Atom processors do not have the extensions. Any virtual machine (FreeDOS or otherwise) will be painful without them. It sounds like your machine has the processor extensions, but you need to ensure they are enabled in the BIOS. Even if you do not use the power saving TSRs or programs that are power aware, the worst that will happen is that the virtual machine running FreeDOS will use one of the host CPU cores. For a desktop system this is not a major problem. On a laptop it will shorten battery life. You have a wide variety of TSRs to choose from - FDAPM and DOSIDLE are my favorites so far. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
