Hello,

Does anybody succeed in booting Win98SE (with Maximum-Decim Native USB 2.0 drivers) from external USB hard disk ?
With the original drivers, I can get it boots OK, but only with USB 1.1 speed and without any hot plug/unplug recognition.
Once applied the USB 2.0 drivers, Win98SE hang after few disk accesses at logo screen. No problem when I pulled back the hard disk
out of its USB enclosure and put it back as internal IDE hard disk.

It is not possible to do.

In order to boot from USB device a BIOS or DOS support is necesary. Also, it is not possible to use Windows driver and DOS or BIOS in the same time. So, in the moment Windows start's it's USB driver the boot drive stops responding.

The conclusion is: Windows has to have USB support disabled, in order to be able to boot from an USB drive. Or, it will be necesary to make a ram drive and to boot the Windows from it.

What version of DOS USB drivers are you using?

I've found using the driver version 2.06(?) is rediculously slow and doesn't run USB2 capable drives/hubs at USB2 speeds (only 'supports' them). Driver v2.20 or v2.24 should get the speed you need and is significantly more stable. Just the lack of hotplug support and such is the only drawback when in windows

@Chozo4

Thank you for all your replies. I used the Maximum-Decim Native USB drivers version 3.3.
How can I find the 2.24 drivers version? Hotplug is not a requirement since probably can plug them before booting. What I expect is to be able
to boot form USB hard disk, and use it USB 2.0 speed.

Thank you in advance.

When you are booting from an USB drive, you are limited to what the BIOS is providing. A driver change will not make any difference, I'm afraid.

This is not correct. Two examples:
1) Linux: USB stack is loaded using first BIOS USB with initrd/kernel (less than 5MB). Then the USB stack uses protected-mode USB 2.0 to exploit the hardware in high USB 2.0 speed.

2) XP/Vista: as with Linux, but without RAM disk in normal booting. This explains also slow boot on some machines with BIOS USB 1.x booting (although with USB2.0-hardware capable). Then afterwards the loaded OS will exploit the USB2.0 through drivers.

@Chozo4:
You mean USBASPI.SYS v. 2.24 ???
And I thought the most recent available was the v. 2.20!
Thanks for the heads up!

@lilas:
Please give a look at these two threads elsewhere:
USB 2.0 + NTFS read/write under DOS, Achieved successfully !
and
Ghosting from Booted USB key Drive
They don't do quite what you want, but they may be a start...

I think there is some mixing of terms, lilas is referring to the Windows 9x drivers, i.e. the ones packed by Maximus Decim, while Chozo4 and dencorso are referring to DOS USB drivers.

@dencorso
Yep, it's pretty newish, here:
http://www.computing.net/answers/dos/usbas...ased/16587.html

jaclaz

We are speaking about Windows 98, here. The boot drive letter will not be accessible after protected mode USB driver start. Also, Windows 98 will not let to use the same drive letter for the USB device as the boot drive has, as the boot drive is DOS compatible mode driven. The finall result is hang during boot, in any case.

@jaclaz:
First of all, thanks for the link! You rock!


Well, lilas needs to boot first, using the BIOS USB support (usually USB 1.1) then move things to a RAM drive and load the DOS USB 2.0 drivers. This will result in the disappearance of the BOOT drive and its letter, from the DOS point of view, hence the RAM drive is really needed. Now it'll be possible to start Win 98SE from the newly created USB 2.0 USBASPI drive using the new drive letter. I never said it was easy. It's not. But it is possible. But, in this context, NUSB cannot be present in Windows because, when Windows loads it, the USBASPI drive will disappear, resulting in a major system crash! So, possible it is, but only in Win 98SE without NUSB. The links I posted above are two alternate ways of doing it up to the point of having USB 2.0 support in DOS. The rest requires a lot of patience, tunning up and messing with the registry. But can be done. HTH.

Yep, which brings us exactly where Sfor left us:



Since there are already a few ways to run Win9x in RAM, there is no need to discuss this at length, most links are in the "old" thread here:
http://www.911cd.net/forums//index.php?showtopic=12326
and on boot-land here:
http://www.boot-land.net/forums/?showforum=53


Now, it would be interesting if we could use something similar to the "Xp Kansas city shuffle":
http://www.911cd.net/forums//index.php?sho...c=21242&hl=
to reduce the amount of data transferred between the USB stick and RAM or reduce Ramdisk size, though on modern machines a "huge" ramdisk of 64 or 128 Mb would be just a fraction of total RAM.

In other words, can we find a minimal set of Win9x files (for example to be loaded through DOS-HMLOAD-grub4dos on internal grub4dos rd), "disconnect" the BIOS access to the USB stick then start loading a miniwindows from the rd and load the rest through Windows USB drivers?


Any taker?

jaclaz

You didn't quite get my point. What Sfor said is quite true but:

One boots from BIOS support (USB 1.1, assuming DOS calls it C:), creates a RAM disk with XMSDSK (let's say D:), locates it with FINDRAMD and transfers everything relevant to the RAM disk (2.88 MB or a little more should be large enough), changes the current drive to the RAM disk (D:), and loads USBASPI and DI1000DD using, say, DEVLOAD. Poof, the original drive letter used for USB boot ceases to exist ( drive C: becomes invalid) and the drive's contents are inaccessible via that letter. But now they are acessible via a new drive letter, created by DI1000DD (say, W:). And since the current drive is the RAM disk, DOS will NOT crash! So, now change the current drive to drive W: and start windows from drive W: and all will go well, EXCEPT in the case in which windows, while loading, starts NUSB. If Windows strats NUSB (or Orangeware), and only in this case the drive Z: will become instantly invalid and the system will crash.
But if the windows image does not have native usb support, nothing wrong will happen, and windoes can really be started from USB, at USB 2.0 speed, provided one corrects all references to the boot drive letter, changing it to Z: in all of MSDOS.SYS, AUTOEXEC.BAT, CONFIG.SYS, WIN.INI, SYSTEM.INI, PROTOCOL.INI, USER.DAT, SYSTEM.DAT and in the main environment. This can be done. The down side is that whatever drives were in the usb ports must remain there during the whole uptime, because unplugging any of them can crash the system. And also that no new USB device can be recognized after the loading of USBAPI. That's what I was talking about. I know it surely is very difficult to get this complex thing working but once working it should require no further adjustments. So, with lots upon lots of patience, *it* *can* *be* *done*. So why don't I do it myself? Well, I have no use for it since my only USB storage devices are flashdisks, and using windows from flash media is a sure way to kill the flash memory due to excessive writing to it. As soon as I have a USB HDD I may try it, but for now I have no plans of acquiring one. But all lilas asked was whether it is possible and I insist it IS. This is untested, AFAIK, so the first one to try it may not succeed at firs or even at all. But, in theory it can be done, and the dos part has been done and works. See the links I posted above in my next to last post before this one (that is, post #7).

@dencorso

The actual stance of people that posted on this board are as I see it:

Lilas:
do not know.

Sfor:
I know and it can be done ONLY through RAM booting.

jaclaz:
I know, it can be done ONLY through RAM booting and it's easy as it is already documented, an alternative could be a "splitted" RAM disk booting (hinted a possible way).

dencorso:
I know, it can be done through RAM booting and it's difficult, because one needs a "splitted" RAM disk booting approach, that I think it should work (described a possible way), I INSISTing that it is possible (through RAM booting)

So, we are saying exactly the same things , with different degrees of optimism or pessimism and different ways to describe the solution, in a nutshell:
1) it is NOT possible without some form of RAM disk booting
2) it is possible with documented "integral" RAM disk booting
3) may work with some form of "splitted" RAM disk booting

jaclaz

jaclaz, my friend, you're quite right! That's precisely it! You rock, you really do!

A note: DOS needs to have the access to the command.com file. If the boot drive letter is to be lost, it is necesary to move the command.com to other drive and to notify DOS about it with COMSPEC enviroment variable.