I've removed all the linux vs windows and USB stuff with 0% DOS relation and send it in private only.
Eric Auer schrieb: > Hi! > >>> I just checked, both Virtualbox and VMware need kernel >>> drivers to install, which is a pain to maintain and to >>> keep up to date... > > It would be a pain in Windows, too, but the Windows > kernel is not updated... :-p XP works fine for me since a couple of years, there are some patches and never broken any application. Vista is no real evolution, it's regression, but there was also no evolution needed. >> most software I like is not available or the >> setup is complicated. Installing those software >> on linux is really a mess, but you are right, >> perhaps someone else installed it. > > As said, the actual experiment on VMware was on a messed > up Windows, not Linux ;-). I never had any trouble when installing VMware on any configuration (windows). > And the guys with multiple VM > servers run both Linux and Windows clients but their VM- > ware hardware is Linux afair. Well, for server hosting linux might be good but as private end user I don't have much fun with linxu for my real system. >> Well, on Windows XP both installers work for me out >> of the box. These software packages are not optimal >> in my opinion (no portable version >> such as for Bochs or Qemu, but at least them work). > > True... A nice installer for Virtualbox or VMware for > Linux would help... Yes. > I mean the nVidia drivers show it > can be done (open source drivers would be easiest...) > but anyway... The main VMware problem was that I tried > on an "old" SuSE 9, tried to keep the installer from > messing too much with my config, and wanting a complex > network bridging between VMware and the host Linux. In > the VirtualBox case, I simply stopped when I saw how > many kernel drivers the package suggested to give me. > Dunno how painful it would have been to continue, and > of course dunno how well-behaved those are in Windows. On Windows I did just install them with default and all worked out of the box. >> Dosemu is not possible in this case. > >> Bochs is VERY slow for installing Windows but I used >> Qemu to do that (only medium slow) and now I have also >> a big Bochs image... > > Hmmm so your experiment depends on installing Windows? Yes. > Then it is cool that you managed to have such a small > image in the end, how do you do that? Windows is only needed in the creation process. (installing the new bootloader) After doing that I could delete the rest. >> 13 MB uncompressed VMware image: >> http://www.badongo.com/file/12699341 >> - Password: 1 > > Password for what? The password will be asked after booting. > Badongo is slow but works without... Yes. >> - choose grub4dos in bootmenu >> - boot either freedos or the virtual image, both will >> hang at initdisk in VMware and in VirtualBox > > What do you mean by "either FreeDOS or the virtual image", > in particular what do you mean by "virtual image" here? Yes, virtual image. I provide a small boot menu in the virtual image. Staring kernel.sys directly and starting an floppy image emulated as floppy (like memdisk...). >>> which partition scheme >>> and which partition types does it use? > >> 1 primary partition, FAT 32, active. > > LBA or not? I think LBA is the default, I never chose CHS, so I *think* it's default LBA. >> It happens if a non-standard MBR is used. The creation of the >> non-standard MBR needs Windows and Windows needs at least 6 GB >> (or so) to install. > > Wow! I assume you mean "that special Vista / similar > partitioning scheme which supports harddisks and RAID > arrays of more than 2 terabyte size confuses FreeDOS" Not directly but some similar complicated thing. >> And the VMware format support is broken (confirmed bug) >> I am waiting for fix and new release. > > Uh oh! What is broken in it? How hard is the fix, do you > already know how optimistic they are about fixing soon? I've talked about this on the Bochs developer mailing list. Someone found a bug in the source code. I mailed the original author and he mailed back fast and told me he will check it out and send everyone an update. We will see how long he will take and how long the next release will take. Mostly releases take from year to year in Bochs but perhaps there are cvs builds, I will see later. >> You can mount virtual disks just with the gui. > > Which reminds me that they also have a way to make > drives or directories visible to both host and client Yes, the shared folder feature. > OS, but of course not for DOS. There are some alternative vmware tools for DOS, I don't remember if it was included, guess not but unsure. It's possible, someone just needs to write a driver. > And I do not know how > the whole story differs from using "networked" drives > with a network between host and client? Pro / Contra? network does not need vmware tools installed, shared folder needs vmware tools installed. no vmware tools = good for paranoid needs in security, but for paranoid needs in security I suggest rather Bochs + different physical computers. shared folders are more easy to setup, the supported operating system is not involved much (no setup sharing...) work just out of the box, but I guess "internally" them are managed thought the network, I did never try shared folders without virtual network card. >> www.mail-archive.com/freedos-u...@lists.sourceforge.net/msg07186.html > >> I hope you have a virtualizer (free), XP (now nearly free), >> TrueCrypt (free), grub4dos (free). > > Hehe. I do not, but the combination of XP, truecrypt and > grub4dos sounds exciting. It is! :) > Does the problem ONLY happen if > you use both grub4dos and truecrypt, It happens right after installing the non-standard bootloader. Note: no encryption done at this time! (It's just a pretest if the bootloader is working and if the user is intelligent enough to enter the correct password he did choose before.) When using BIOS -> hd0 -> MBR -> NTLDR / boot.ini -> grub4dos... -> [1] chainloading kernel.sys is working fine -> [2] chainloading virtual floppy is also working fine (No matter if FAT32 or NTFS... when using NTFS and [1] command.com can not be found, this is normal, but no crash... when using NTFS and [2] hd0 is not readable, only after loading NTFS driver, also no crash...) > or is using one of > the two (which? any?) already enough to trigger it? Like said, it happens only if a non-standard bootloader (TrueCrypt) was loaded before at this time. When booting "normal", like from other hd or floppy there is no crash. > Usual > extra question: Did another DOS (EDR-DOS, Win9x-DOS...) > "survive" your special setup better than FreeDOS? MS-DOS 6.22 you can forget because not FAT32. 7.0, 7.1, 8.0 also crashed. EDR-DOS also crashed. > Maybe > there is a general problem with truecrypt. Maybe... Well, DOS is not supported in TrueCrypt and this approach is not planed. :) > I remember a > similar problem existed with OnTrack / similar LBA int13 > helpers, doublespace and so on: If you did not boot the > intended OS in the intended way, you had trouble accessing > the disk. Intended OS and intended way might be XP and > "not grub" in your case... Yes. >> To install XP you need at least 6 GB (or so). NTFS is not >> compatible with DOS (as bootup)... > > Hmm so you try to let DOS and XP share one FAT32 Yes. (normally this works well) As an optimal solution DOS could run also from encrypted partition. :> > partition > (you say you have only 1) and that partition is crypted? In my tests, yes. >> [Freedos-user] computer restarting without error message >> Michael Reichenbach >> Sun, 01 Jun 2008 11:56:44 -0700 > > Wow, that is a while ago... Yes, since then I am fighting with Bochs, vmware disk support and the .img. For every problem I solve a new one appears ;) Finally I had the glorious idea to ask you to use VMware (Player) or VirtualBox. > Note that depending on HOW truecrypt lets XP boot from > crypted partitions, the boot loader might get only some > form of limited access. Note again: there was NO encryption involved yet, just a non standard bootloader who is crashing FreeDOS. > For example only LBA or only CHS > or only certain files, or maybe they replace the boot > loader of XP itself with some sort of "second stage of > truecrypt" which in turn loads more of XP which finally > loads some XP specific truecrypt driver? I looked at the source and as far I understand them initially hook the BIOS calls and provide mange the real mode access, and later for 32/64 bit a special driver is provided. > Note that I am wildly speculating and probably wasting > my and your time by writing a lot of text about things > that I do not really know at all ;-). I hope you are interested enough to test it yourself at some point. -mr ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
