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?
> 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
> 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
> 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.
> 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 <firstname.lastname@example.org>
> 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
> 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
> General>Basic: OS = Other, Version = DOS
> System>Motherboard: 32 MB, Chipset PIIX3,
> ...Processor: Cap 87%
> ...Acceleration: uncheck Enable VT-x/AMD-V
> Storage: IDE Controller, FreeDOS...vdi image
> Network>Adapter 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.
> 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
John S Wolter
LinkedIn: johnswolter <http://www.linkedin.com/in/johnswolter>
- 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
Freedos-user mailing list