Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Hi, On Mon, May 21, 2012 at 11:52 PM, Jack wrote: > >> VBox lets you choose how much % of processor to use, so it doesn't >> have to use 100% all the time. I just wonder whether their bugs are >> due to their tweaked BIOS or some hidden instruction incompatibility >> or what. :-/ > > My own personal "guess" is that their bugs are more likely due to > incompetent BRATS "messing around" with hardware about which they > really are NOT qualified to "mess with"!! I wouldn't be that harsh, it's a "complex" processor family, pun intended. ;-) But I do take issue with the idea that "it's open source, fix it yourself". Seriously, anybody who's ever tried to build most free/libre software has seen how ungodly it often is. (Though closed source is presumably just as bad, maybe worse.) Why coders are so ... mind-numbingly opaque is beyond me. https://www.virtualbox.org/wiki/Build_instructions VirtualBox seems no different. Though of course I'm only peering at the Windows portion, so I'm a bit biased, but you gotta start somewhere. Without even downloading a lick of code, I'm confronted with a *TON* of dependencies: https://www.virtualbox.org/wiki/Windows%20build%20instructions Red flags that make me want to scream: * kBuild (modified GNU make) that has "currently 0.5 people on the planet that fully understand it" * MinGW (old GCC 3.3.1, not 3.4.[25] which won't work) * rare build issues on various Windows (2k, Vista) for obscure reasons, e.g. requiring Cygwin Ash shell explicitly (and no support at all for Jack's favorite NT 4) * Qt 3.3.x (not 4.x) needed for frontend Granted, I know some of this is unavoidable: things change, regressions happen and new versions are released, different devs prefer different build tools, but I just really hate the complexity in building things. It's no wonder that more platforms aren't supported or that more people don't contribute ... it won't freakin' build! IT'S TOO VOLATILE! (Yeah yeah, welcome to the world, software has always been like that. Though I don't have to enjoy it.) -- 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] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
-- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! > > I've never looked at UIDE closely, but there's "always" room for space > improvement in assembly!! ;-) Maybe you should "look again" at the UIDE.ASM source file! I have "boiled down" its logic so many times that finding any MORE "spare" bytes is REALLY becoming difficult, even for me!! > VBox lets you choose how much % of processor to use, so it doesn't > have to use 100% all the time. I just wonder whether their bugs are > due to their tweaked BIOS or some hidden instruction incompatibility > or what. :-/ My own personal "guess" is that their bugs are more likely due to incompetent BRATS "messing around" with hardware about which they really are NOT qualified to "mess with"!! -- 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] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Eric, > When DOS detects an unreliable floppy change line hardware, > it should use the floppy label / serial / similar to detect > changes in software ... How does DOS ever detect that any hardware is "unreliable"?? > I agree that it is nice to disable floppy caches, but maybe > the kernel actually does something detectable in REACTION to > detecting a floppy change? For example it might issue an Int > 13h "drive reset" command which in turn can be caught by the > UIDE2 driver and treated as a "flush cache for THAT drive" > event? ... What do you mean "maybe"?? You and others are the "kernel experts" for FreeDOS, not me, as I still run V6.22 MS-DOS!! Also, I say again that I am NOT interested in any "specific logic" from the MS-DOS kernel, or the FreeDOS kernel, or in fact ANY kernel, for detecting diskette changes. My worry is that such logic may NOT be "generic", and I want UIDE or UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes (despite Bertho's worries about "flaky" change lines!), and so I will leave my drivers that way. Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS "system calls" and I also want to keep THAT "generic" feature in my drivers, as well! >>> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >>> .SYS file! But, I shall find a way! > > Thanks :-) By the way, any chance to work around the VirtualBox > huge-delay problem? Not without knowing WHY they take such a huge delay! In any case, UIDE and UIDE2 must "scan" for PCI-bus devices, so they can "relate" the PCI device-addresses to the addresses posted via Int 48h requests. That way, I know the UltraDMA address to use for every controller, since UltraDMA addresses are NOT part of Int 48h -- BAD error by the EDD BIOS people, in 1995! If the "VirtualBox" people cannot fix the huge delay in their PIIX3 logic, UIDE or UIDE2 still have their /E switch and can still do disk caching, after the BIOS handles disk I-O. > If you prefer the BIOS way, would int 1a.b103 be an option? It > scans by PCI class so you do not have to loop over bus/device. My drivers are ALREADY doing a PCI scan by class-code, so the huge-delay problem is not related to this. > Note that for example PCISLEEP only uses raw I/O in getpci and > skips looping over functions if function 0 of a bus and device > number pair return "PCI ID -1". So you scan only 1 out of 8 in > such cases. Each bus has 32 device numbers to scan. Also, often > you have far less than 256 bus numbers in use, saves much time. Doesn't matter. A scan for devices by PCI class-code returns only devices that match the requested class/subclass/function, so I lose no time by checking unnecessary busses/devices. In any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running "VirtualBox"! Also, better if you refer to "UIDE" in general, since UIDE and UIDE2 assemble from the same UIDE.ASM source and do nearly all the same initialization functions. A few differences re: how they allocate XMS memory and where they load, but their device scanning and setup is 100% the same. Jack R. Ellis -- 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] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Hi, N.B. this was mailed to "freedos-user", not freedos-kernel. On Mon, May 21, 2012 at 9:34 PM, Eric Auer wrote: > >>> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >>> .SYS file! But, I shall find a way! I've never looked at UIDE closely, but there's "always" room for space improvement in assembly!! ;-) > PS: The UIDE issue is described in Ulrich's wiki page which also > is a good GENERAL "how to install FreeDOS 1.1 on empty harddisk" > document :-) I would also suggest to make /NOHI the KEYB default! > The KEYB thing might be due to rawer-than-EMS-style UMB attempts? Is anybody working on FD 1.2? I haven't heard anything (and don't think we need it just yet anyways). Switching things around is, I guess, that person's ultimate decision (Bernd??). I hate to open up a can of worms (so tedious ...), but did Bernd or Jeremy ever publish any scripts to build the .ISOs? Meh, just the "idea" sounds difficult. Bah. But we can still dream, can't we? ;-) > PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to > one of the default driver sets in FreeDOS 1.1 config / autoexec. VBox lets you choose how much % of processor to use, so it doesn't have to use 100% all the time. I just wonder whether their bugs are due to their tweaked BIOS or some hidden instruction incompatibility or what. :-/ -- 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] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Jack, kernel experts, > On REAL (old) PC hardware, the existence of floppy disk changelines > is not guaranteed; even if the line is present AND properly connected > it MIGHT be flaky or not work at all; or the BIOS might not update > the bits you expect. MS-DOS (and, I presume, good DOS clones as well) > will use alternate means and kluges to check for media change in the > absence of a (credible) change line. Your DOS drivers could have been > relying on DOS for checking media change, not on the BIOS or direct > HW interrogation in the 1st place! When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software. Maybe FreeDOS does this, maybe not? Is a change in label / ID always a trigger for a change event, or only in context of having detected hardware reliability troubles before? > Offering the user an option to switch diskette caching off is much > better. As you are aware, SMARTDRV allows a user to select... I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an int 13h "drive reset" command which in turn can be caught by the UIDE2 driver and treated as a "flush cache for THAT drive" event? Depending on other factors, even flushing the caches for all drives or all floppies would still be better than a situation where the cache still contains data from old disks which are no longer inserted in the drives: Rather be SAFE, have some performance loss (due to extra flushes, less cache efficiency is reached and the flush itself also takes time) than SORRY (data loss due to mismatch in cache / real data). If the kernel issues eg. int 13.0 after detecting a floppy change - which it should be able to do even if the change line is unreliable - and UIDE2 reacts to that with a flush, DOS can take care of the reliability while UIDE2 still only has to care about int 13 calls :-) Also this makes it safer to use UIDE2, as is does not need manual /N safety options. >> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >> .SYS file! But, I shall find a way! Thanks :-) By the way, any chance to work around the VirtualBox huge-delay problem? Apart from configuring VirtualBox to use a different virtual chipset, I mean. It seems that UIDE2 code, in particular I_ScnC, I_PCIC and I_PCID uses BIOS calls (not fast? raw I/O) to scan ALL possible bus/device/function numbers, thus ignoring the "last used bus number" returned by int 1a.b101.0? If you prefer the BIOS way, would int 1a.b103 be an option? It scans by PCI class so you do not have to loop over bus/device. Just some ideas, of course, but might also help to make UIDE2 more robust with other flawed "hardware" or BIOS versions :-) Note that for example PCISLEEP only uses raw I/O in getpci and skips looping over functions if function 0 of a bus and device number pair return "PCI ID -1". So you scan only 1 out of 8 in such cases. Each bus has 32 device numbers to scan. Also, often you have far less than 256 bus numbers in use, saves much time. By the way, PCISLEEP only supports the "newer" mechanism 1, the "ancient" mechanism 2 for I/O is not supported but rarely used. See also: http://wiki.osdev.org/PCI and also note that SYSLINUX 3.05 calls mechanism #2 a "hideous old hack" yet supports it: http://www.syslinux.org/old/history.php As you see in PCISLEEP source code, mechanism #1 is easy and compact to implement :-) Regards, Eric PS: The UIDE issue is described in Ulrich's wiki page which also is a good GENERAL "how to install FreeDOS 1.1 on empty harddisk" document :-) I would also suggest to make /NOHI the KEYB default! The KEYB thing might be due to rawer-than-EMS-style UMB attempts? > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8 > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9 PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to one of the default driver sets in FreeDOS 1.1 config / autoexec. > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_7#Possible_Solutions:_2._Use_DOS_Power_Management -- 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] Why DOS shouldn't be emulated...
On Wed, May 16, 2012 at 4:52 PM, Michael Robinson wrote: > There has been a fair amount of just run it under emulation being said. > One of the advantages of DOS is that it isn't a modern operating system. > An easy way to install Freedos safely to a desktop computer involves the > following: > [...] > > Now on a 64 bit computer, Freedos may have to be run under emulation. > A variant of these instructions is to get a PIII or P4 32 bit computer > and dedicate that to Freedos. > > The problem with emulation is that you are throwing the simplicity of > DOS away and introducing compatibility issues. Emulation is getting > better and if you are constantly rebooting between Freedos and Linux or > Freedos and Windows, emulation may be a necessity. Still, a good KVM > switch and a dedicated DOS computer also solves the reboot issue. > Freedos will work fine on anything from an 8086 up to a Pentium 4. > Don't underestimate the utility of dedicating a computer to DOS. > > A thought that comes to mind is that you don't want to worry about your > kids who are interested in playing video games screwing up your > computer. A dedicated DOS machine makes a lot of sense for that. > Hardware is sometimes better for running DOS, and sometimes a virtual machine is better for running DOS. It really depends on what you are doing. For example, when I'm writing code for FreeDOS, I'll have a copy of FreeDOS booted in DOSemu. I run Linux, with lots of nifty developer tools and editors, and I just find it's easier for me to do my FreeDOS work there (say, in GNU emacs) while I also have a web browser open for email, or Facebook, or whatever. When it's time to compile, I just bring up the DOSemu window and compile under FreeDOS. Doing this in DOSemu is great for my coding because DOSemu can boot an instance of FreeDOS from a directory on Linux. So when I edit files under Linux, I'm saving them to a directory under Linux, and they are immediately visible to the FreeDOS session in DOSemu. However, let's say I wanted to play DOS games. I might do that under an emulator like DOSemu (and I have) but in certain cases the emulator might just get in the way, not emulate the hardware as well as the DOS game would like. So in that case, it would be better to set up a dedicated PC to play those games. I've helped several friends to do this, set up an older machine (which would otherwise be tossed out) to play DOS games. That old PC may not run the latest version of Windows very well, but it does a great job of playing DOS games. Similarly, there are lots of cases where dedicated hardware is better. Controllers, embedded systems, etc. all require actual hardware to do the job. You wouldn't set up a Linux box just to run DOSemu + FreeDOS, to support an embedded application. You can do a multiboot system with FreeDOS on it, no problem. What you've described would work. I used to use a program called PC Commander (I think that was the name) that was a great multiple operating system loader, and we used this at my work when we first moved to Windows 95, long ago. GRUB, XaoS, and other free boot loaders will do the same job. My personal preference is: if I'm going to set up a hardware system with FreeDOS on it, I'd rather it be a dedicated system. Nothing wrong with doing a multiboot system, just my preference. Simpler that way, less to go wrong. -jh -- 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] Prevent boot from Floppy?
On Mon, May 21, 2012 at 4:06 PM, Wolfgang Schechinger wrote: > Hi Jim, > > your suggestion helped: The boot screen (when booting FreeDos in VirtualBox) > normally disappears so quickly, that it actually doesn't show up (visibly) > unless you press F12 while launching the VM. > > This made me realize that I actually need to find a solution to (force to) > drop any mounted floppy image before the VM is booted, to prevent that the > floppy's boot sector is executed. That's what I actually need. > > Best reagrds, > > Wo Glad that helped! You might consider simply removing the floppy image from the virtual machine definition in VirtualBox when you don't need to boot from floppy. Or, you may want to adjust your BIOS boot order, so that "floppy" appears after "hard drive". When I've worked with virtual machines, that's usually one of the first things I do: set the VM BIOS to boot from hard drive first, then CDROM, then floppy. That way, when I boot my fresh virtual machine using a mounted CD image of FreeDOS or Linux, it boots the CD first (because the hard drive doesn't have anything on it yet, no boot loader.) After the installation is done, if I've forgotten to unmount the CD image from the virtual machine, it doesn't matter because the VM will boot from hard drive anyway (because it now is a valid bootable medium.) -jh -- 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] Prevent boot from Floppy?
Hi Jim, your suggestion helped: The boot screen (when booting FreeDos in VirtualBox) normally disappears so quickly, that it actually doesn't show up (visibly) unless you press F12 while launching the VM. This made me realize that I actually need to find a solution to (force to) drop any mounted floppy image before the VM is booted, to prevent that the floppy's boot sector is executed. That's what I actually need. Best reagrds, Wo -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- 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] Can I accidentely overite my Windows 7 install
On Wed, May 16, 2012 at 8:16 AM, Ben Edwards wrote: > Hi, I have created a small fat32 patision on my Intel Mac. I have Mac OS X > and Windows 7 (NTFS) installed on the box. When I run the freedos 1.1 CD it > gives me the option to install it on C: and cant tell me how big the volume > is. Am I correct in thinking it wil only install on fat32 so I am not in > danger of screwing up my Win7 or Mac installes? > Been a while since I did anything with Bootcamp - I prefer VMs rather than dual-booting like this. However, you *should* be ok. FreeDOS doesn't recognize NTFS partitions, so while these would show up as allocated space, FreeDOS *shouldn't* think your NTFS partition was "C:" and try to reformat it as its own. (Microsoft might do that to a FreeDOS partition, however, so be careful.) But I think your limiting factor is that Bootcamp is fairly simple, IIRC. I experimented with Bootcamp on an Intel Mac a while back, and I think it had trouble if I tried to put a bootloader on the PC side, to boot more than one PC operating system (in my case, Linux, and Windows.) Maybe Apple has changed that. I tried that not long after Apple introduced Bootcamp, and we got an Intel Mac at work to experiment on. -jh -- 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] Prevent boot from Floppy?
Sun, May 20, 2012 at 5:10 PM, Wolfgang Schechinger wrote: > Der experts, > > may I ask another question: > > Is there a way to make FreeDos ignore that there is a floppy present upon > boot, i.e. force a boot from the harddrive? Again only a problem when running > it in a VM, I think, as on a hard PC, you may set the boot options in the > BIOS. > Hi. The best option here is not to do this at the operating system level, but at the BIOS level. You mentioned in your email that you can set the BIOS options when booting on a hardware PC. That same BIOS option exists in true virtual machine emulators. If you are using VMWare, VirtualPC, Bochs, or some similar virtual machine emulator, you will have a BIOS present in the virtual machine. When the VM boots, you should see a message to press a key combination (usually f11 or f12) that will bring up the BIOS setup. If you are using a different virtual machine emulator that does not provide a BIOS (such as DOSEmu) then I'm not sure what you can do to ensure FreeDOS boots from hard drive instead of floppy drive, other than not mounting a floppy image on the emulator when you boot it. I hope that helps you. -jh -- 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] Prevent boot from Floppy?
Hi! >> Is there a way to make FreeDos ignore that there is a floppy >> present upon boot, i.e. force a boot from the harddrive? Normally you would use your BIOS / CMOS setup to select which has priority - harddisk or floppy or USB or CD/DVD or maybe network or other, depending on BIOS support... Sometimes you can also get a boot drive selection menu pop up during boot by pressing a hotkey at that moment. In dosemu, you can run "xdosemu -C" or "xdosemu -A" when you configured both to be bootable, for example like: $_vbootfloppy = "diskimage.bin +hd" $_floppy_a ="threeinch" $_hdimage = "freedos fatimage.bin" The mentioned file names are files or directories (!) in ~/dosemu/ and the config is in ~/.dosemurc but it is common that dosemu supports some other locations for those files as well. The "+hd" means that you can boot from either floppy or harddisk. I assume other virtual computers also let you configure from which drive you want to boot. You can also install a boot manager ( grub4dos, syslinux, grub, *metakern* ) on the floppy. The boot manager can either make sure to ALWAYS ASK you from which disk you want to boot or it can be configured to ALWAYS boot from HARDDISK (maybe giving you a chance to press a key to stay on floppy). If you do a normal "SYS A:", you configure the boot- loader on the floppy to ALWAYS boot from FLOPPY. Note that all three "always ..." only apply when the BIOS tries to boot from the floppy at all - but I recommend to configure the BIOS to default to ignoring bootable floppies, also reduces virus risks a bit :-p You can always temporarily enable floppy booting again in your BIOS config / setup if you really want to boot one... Of course "always skip the floppy and boot from for example the harddisk" could also be implemented with not-bootable floppies, forcing the BIOS to skip (maybe with a warning message) to the harddisk or some other candidate drive. I hope this helps you to understand both problem and solution :-) Also, DOS boot loaders do know from which medium you boot DOS, but of course only the boot loader on exactly that medium itself is run. So you can simply put the settings for whatever you want to happen when the BIOS attempts to boot from floppy on THAT floppy! 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-user Digest, Vol 636, Issue 3
On 20/05/12 23:19, freedos-user-requ...@lists.sourceforge.net wrote: > Subject: [Freedos-user] Prevent boot from Floppy? > To:freedos-user@lists.sourceforge.net > Message-ID:<20120520221020.182...@gmx.net> > Content-Type: text/plain; charset="utf-8" > > Der experts, > > may I ask another question: > > Is there a way to make FreeDos ignore that there is a floppy present upon > boot, i.e. force a boot from the harddrive? Again only a problem when running > it in a VM, I think, as on a hard PC, you may set the boot options in the > BIOS. > > Thanks! > > Wolfgang > > > -- Dipping my toe in the water on this list... I recently installed FreeDos on both a "real" machine (500 MHz Pentium III, 512MB RAM, 6.3 GB hard drive, CD reader) and a VirtualBox VM running on my main Linux machine. VirtualBox offers the option to enable or inhibit boot from each of hard drive, CD and floppy, and to vary the order of priority between them. I'm afraid I can't speak for any other VMs. Ian -- Ian Park email: i.d.c.p...@ntlworld.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] Virtual floppy change problem
Reply to Ralf A. Quint (2012-05-21 00:45) >Bertho Grandpied wrote: >>Raises the question of what a Ramdisk should do in order to >>"properly" identify itself to smartdrv... impersonate MS-RAMDRIVE, maybe ;=) > For starters, use a media descriptor byte value of 0xFA in the BPB... This may be a good recommendation to make to someone who would write yet another ram drive for DOS systems. However an 'FA' media byte is *not* how MS-Sartdrive, aka Wincache, aka Bambino... would tell a ramdrive from a hard disk partition. Misc notes: - 1. MS-Ramdrive sets its media = F8 2 : contrary to popular belief, a media descriptor = FA *was* used by (some obscure) *real disk gear* known to (MS-)DOS. >>I suspect a mix of bad faith and lazy coding on behalf of MS, but - >>whose "fault" ever it may be, the problem - once recognised! - was >>easily worked around by explicitly excluding the RD on smartdrive's >>command line. >yeah, that good old "Microsoft bashing without hard facts" trick, >never gets old... :-( A great classic indeed;=) -- Czerno -- 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
