SOLVED: Duse - issues listed (usb drivers in dos)

Discussion in 'Computer Information' started by jameshanley39, Oct 2, 2007.

  1. DUSE issues

    I don't plan on using DUSE again, I only used it for a day and a
    night. But noted down the issues.

    Dos boot disks have had 3rd party utilities to view NTFS, and now

    Win XP PE (like windows itself, booted off a cd, a LIVE cd in linux
    terminology) views NTFS, and USB too. I see no reason to do any of

    Easier than duse is to plug a drive in internally. All my so-called
    usb drives are actually internal ones with a usb-ide adaptor. If
    somebody really needs a fan, they can get an enclosure, and can then
    take the drive out. There is no point having an extenral usb drive at

    Other options to view files on a USB drive would be install win xp or
    find a win xp machine and plug the drive in, than bother with this!

    Anyhow. Onto DUSE..

    Setting it up is quite quirky. was useful in suggesting an autoexec.bat and
    config.sys that worked. And linking to DUSE and its documentation.

    this site was good. Giving an image of a disk. A Quick way to get
    oneself started. Though autoexec.bat and config.sys require some
    tweaking. And the disk doesn't have many useful dos files like

    mr , true to form, is expert in what works and what
    doesn't, he probably gets many emails.
    But he didn't mention what didn't work.. or technicalities. It's more
    like, "this just works" "look, no hands". DUSE is quirky, so who
    knows why certain things don't work. But he didn't mention what didn't

    In one example of getting it working , he mentions



    from what I tried, I don't think that gets the CDROM working. So i'd
    do it a bit differently to get the cdrom working, . First, no CDROM.
    So no need for the mscdex line. So, can be blank autoexec.




    I'd add a few points.

    He didn't include emm386 - good

    In config.sys, you do not want to put emm386.exe

    If you do, DUSE can give an error like
    'dos in protected mode'

    He didn't start DUSE from the command line - good

    The DUSE documentation mentions that instead of starting DUSE from
    config.sys , you can start it from the command line.
    duseldr duse.exe
    However, I found that when I do that, and I try something as simple
    edit config.sys
    I get an error about there not being enough memory .
    If I load duse.exe from config.sys, I don't get that error.
    BTW, if you included emm386, then the error you can get when starting
    DUSE from the command line is "dos is in protected mode"

    DUSE will see your CDROM in a sense.
    A popup comes up, and detects USB devices ..
    like your usb hard drive, or usb cdrom.

    This is without even any CDROM drivers.

    The hard drive will be detectable readable.

    The CDROM will not.

    (Although I seem to recall the stefan2000 boot disk one time when it
    worked, it saw my cdrom and not my USB hard drive. And it had no
    generic cdrom driver. So I don't know how that happened. I look at
    that as an exception, and however it happened, it's no use anyway 'cos
    I couldn't see my usb hard drive, and i haven't been able to repeat

    Consider this a hypothesis!

    What DUSE has done, is effectively made it a bit like as if you had an
    internal cdrom drive.

    You can't read it yet, you need a driver for it. And there are generic
    drivers. An old one, is oakcdrom.sys
    downloadable from here

    Any win98 boot disk with cdrom access, eg from would have
    that kind of setup on it, a working example.

    In short, you'd do something like this in autoexec.bat and config.sys

    ( used those switches besides the /D:USBCDROM Another
    site mentions /M:15 , it's probably a good option)

    DEVICE=A:\oakcdrom.SYS /D:USBCDROM

    Traditionally, in autoexec and config.sys you can do /D: anything,
    it's just an identifier so you can do e.g. /D:asdf The use of /
    D:MSCD0001 seemed to be what generic cdrom driver installation
    software did. THe important thing was only that they matched, that you
    used the same identifier for config.sys and for autoexec.bat But with
    DUSE, you have to use /D:USBCDROM

    Also, I think devicehigh and loadhigh/lh only apply to when emm386 is
    loaded. The computerhope site mentions using that, but with DUSE you
    don't load that, as mentioned.

    d) mentions
    device=a:\usbaspi.sys in an example of using DUSE. But didn't mention
    that that file is not part of DUSE.

    Wikipedia in this article about some form of DOS, says
    " external DOS USB drivers (such as DUSE, USBASPI and USBMASS) for
    storage devices work with some effort and luck "

    So according to that, USBASPI is an alternative to DUSE
    Other pages on the web (posted by madmaxusb?) have mentioned
    DI1000DD.sys(prob an alternative to duse, by Novell). And some have
    used that with usbaspi.sys

    One page somebody posting said you don't use USBASPI.SYS and DUSE
    together. I presume he said that because they are alternatives.

    most of these points have been related to the site
    But the stefan2000 disk that I mentioned, loads emm386.exe and loads
    duse from the command line, so if you used that disk you'd have to
    amend that.
    I don't think you need to use that though. You can just make a win98
    boot disk e.g. with, or from windows. And rewrite
    autoexec.bat and config.sys accordingly. They only need be 1-3 lines.

    autoexec, the mscdex line

    config.sys, the himem.sys, cdrom driver(like oakcdrom.sys), and
    duse.exe lines.

    f)He referred to "A:" - good (though i did manage to boot C and refer
    to C, but there were issues)

    The issue is because of how DUSE operates..

    Even if booting off a floppy, you'll notice this.

    I think, NTFS drives become a bit visible, C now pointed to my NTFS
    You can't read it.
    dir c: gives "General failure reading drive C"

    D is now my FAT32 USB hard drive.

    That's no big deal to figure out. But there are issues if you are
    booting from C.

    Because as soon as DUSE is loaded, it become D !!

    The config.sys ended by loading DUSE

    Then you get an ERROR, DOS looks for (it does that at
    certain times or when loading some things), and it can't find , a classic error. It asks where to find it, and you have
    to tell it D:\COMMAND.COM or if you have a boot disk on you, you
    could give it A:\COMMAND.COM
    I don't think you can easily stop that error coming up. I tried SHELL,
    like SHELL=D:\COMMAND.COM and something like it, in autoexec, but it
    didn't help.

    If you want a USB CDROM to work, you'll probably want to add another
    line in config.sys for a generic cdrom driver like oakcdrom.sys But
    that line if it's after the DUSE.EXE will have to refer to D:
    \oakcdrom.sys not C:\oakcdrom.sys
    So it's easiest to just put that line for a USB CDROM, before the
    DUSE.exe line. Then it can be device=C:\oakcdrom.sys instead of

    you'd either say
    device=d:\oakcdrom.sys /D:USBCDROM


    device=c:\oakcdrom.sys /D:USBCDROM

    but if you do

    device=c:\oakcdrom.sys /D:USBCDROM
    then a config.sys error comes up.
    ('cos by the time it reaches the beginning of line 3, oakcdrom.sys is
    on D! So is himem.sys and duse.exe btw! But the problem would be in
    referring to a file that doesn't exist, which happens here with
    oakcdrom.sys Whereas himem.sys and duse.exe were used/loaded from
    files that existed, and now they're in RAM and don't need those old
    files - i guess)
    jameshanley39, Oct 2, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.