VOGONS

Common searches


Reply 20 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member
Yoghoo wrote on 2023-12-12, 10:26:

Tried it today with devload and sysload to start netdrive.sys from the command line instead of the config.sys.

This works nicely when not using a cd-rom driver. When using a cd-rom driver the netdrive.sys loads correctly but takes the drive from the already assigned cd-rom. And when it tries to mount the image with netdrive.exe it hangs after the packet driver is connecting. So this indeed confirms what mkarcher said above.

We need to be very clear about this - DOS assigns drive letters to device drivers. Device drivers do not take drive letters. If you are having a conflict it is not the device driver causing it.

Did you load mscdex to get the drive letter before loading the device driver?

Reply 21 of 196, by Yoghoo

User metadata
Rank Member
Rank
Member
mbbrutman wrote on 2023-12-12, 14:32:

Did you load mscdex to get the drive letter before loading the device driver?

Tried it before and after loading mscdex. In both cases it will take drive letter E:. So it's overwriting the assigned drive for my CD when mscdex is already loaded and was assigned drive letter E:.

Reply 22 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

You might want to start another thread to ask about this, as I suspect it's a more general problem.

Once again, device drivers don't take drive letters - DOS tells the device driver what letter to use when it initializes the driver. If DOS is telling the device driver to use a drive letter that is already in use then something seems to be terribly wrong.

If you find a small RAM disk device driver I would try loading that after MSCDEX; I'm willing to bet you'll have the same problem. (Both devices drivers will look the same as far as DOS is concerned.)

Reply 23 of 196, by keenerb

User metadata
Rank Oldbie
Rank
Oldbie

I guess that's why ETHERDS lets you specify the drive letter, it's an executable that you can run and unload on-demand. I do rely on the mapped drive letters so that my vintage machines all have the same F: and G: drives, but I'm still going to give this a shot. I am curious if it solves some of the issues etherdfs has with some apps like Geoworks...

Reply 24 of 196, by Yoghoo

User metadata
Rank Member
Rank
Member
mbbrutman wrote on 2023-12-12, 15:31:

You might want to start another thread to ask about this, as I suspect it's a more general problem.

Once again, device drivers don't take drive letters - DOS tells the device driver what letter to use when it initializes the driver. If DOS is telling the device driver to use a drive letter that is already in use then something seems to be terribly wrong.

If you find a small RAM disk device driver I would try loading that after MSCDEX; I'm willing to bet you'll have the same problem. (Both devices drivers will look the same as far as DOS is concerned.)

If I use XMSDSK to create a RAM disk it creates it as a F: drive. So that works correctly (drive letter after the CD rom).

Not creating a another thread btw. Not looking for a hack to get it working the way I expect it should work. It's just an observation/feature request. Do with it as you like.

Reply 25 of 196, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie

I know nothing about DOS device drivers or really anything about developing software for DOS at all.

But is it possible to allocate a device (which gets a drive letter) and then later release/uninstall that device (and the letter with it)?
If so, one could just allocate bunch of stub-devices with letters until the desired letter is achieved and then release all the previous stub-devices releasing those drive letters.

But i bet you already thought of it and there's a reason it's not already developed. (For ex. device driver is incapable of determining the letter it got for itself or something)

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 27 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member
ivdimkra wrote on 2023-12-12, 14:21:

I'm testing netdrive server on linux (ubuntu). Works fine, but can i run netdrive serve like a daemon, without terminal commands input ? I wish to start it from systemd service unit ..

I'll get that added.

At the moment I use it in the background, but I run it under "screen" so that I can just re-attach as needed to look at it. I was assuming that I would need debug info from it for a while so I didn't think about adding a true daemon mode.

Reply 28 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member
Yoghoo wrote on 2023-12-12, 10:26:

Tried it today with devload and sysload to start netdrive.sys from the command line instead of the config.sys.

This works nicely when not using a cd-rom driver. When using a cd-rom driver the netdrive.sys loads correctly but takes the drive from the already assigned cd-rom. And when it tries to mount the image with netdrive.exe it hangs after the packet driver is connecting. So this indeed confirms what mkarcher said above.

Where are you getting devload and sysload from? My version of DOS (PC DOS 6.3) doesn't have those, and I'd like to understand what's causing the problem. Are you using them under FreeDOS or a different DOS?

Edit: Using FreeDOS 1.3 I ran CDROM.BAT from FREEDOS\BIN and it assigned D: to the CD-ROM. Then I used DEVLOAD in FREEDOS\BIN to load NETDRIVE.SYS and it was assigned E:. And then for giggles, I tested both and they were fine.

Can you provide some details on what DOS you are using? Everything shipped with FreeDOS 1.3 works as expected.

Reply 29 of 196, by Yoghoo

User metadata
Rank Member
Rank
Member
mbbrutman wrote on 2023-12-12, 21:57:
Yoghoo wrote on 2023-12-12, 10:26:

Tried it today with devload and sysload to start netdrive.sys from the command line instead of the config.sys.

This works nicely when not using a cd-rom driver. When using a cd-rom driver the netdrive.sys loads correctly but takes the drive from the already assigned cd-rom. And when it tries to mount the image with netdrive.exe it hangs after the packet driver is connecting. So this indeed confirms what mkarcher said above.

Where are you getting devload and sysload from? My version of DOS (PC DOS 6.3) doesn't have those, and I'd like to understand what's causing the problem. Are you using them under FreeDOS or a different DOS?

I'm using MS DOS 6.22. I downloaded a driver pack from archive.org which includes them (search for: dos drivers archive.org). Devload.com and loadsys.exe (not sysload which I wrote incorrectly) are in there. Both are external utilities and were never part of PC/MS/DR DOS. Only Freedos has a similar tool included.

Reply 30 of 196, by mkarcher

User metadata
Rank l33t
Rank
l33t
Yoghoo wrote on 2023-12-12, 14:42:
mbbrutman wrote on 2023-12-12, 14:32:

Did you load mscdex to get the drive letter before loading the device driver?

Tried it before and after loading mscdex. In both cases it will take drive letter E:. So it's overwriting the assigned drive for my CD when mscdex is already loaded and was assigned drive letter E:.

MSCDEX is not a DOS block device driver and does not influence DOS driver device letter assignment. In DOS, there are two ways in which you can install a handler for a drive letter:

  • The first one is to provide a block device driver. This kind of driver can read (and possibly write) sectors of a (possibly virtual) disk. DOS then adds its FAT driver on top of this driver so that you can access files on the drive. You can not teach DOS any new kind of file system this way. The block device driver does not get any clue about opening and closing files. It does not deal with file name. The only thing it deals with is sectors. Drive letters are assigned to block devices starting at C:, floppy drives do not count, they get the dedicated A:/B: letters; every partition on BIOS-supported hard disks is a different "block device". There is no way of assigninig specific letters to block drivers.
  • The second one is to install a hook for opening files on a specific drive letter. This code path is called the "network redirector", as this way of providing a virtual drive allows to redirect the open call (and if it succeeds, also the read/write/sync/close calls) to somewhere else, e.g. a network server. When installing a redirector, you can specifify which drive letter you want to listen to. If a file on that drive is going to get openend, DOS will call the redirector for this drive instead of the DOS-integrated FAT driver. You can use the network redirector interface to implement network file access (the DOS LANMAN client uses this interface, as does the VLM version of the Novell client, or does ETHDOSFS), or to implement file systems that the DOS kernel does not understand. MSCDEX is a "ISO9660 filesystem driver" that uses the network redirector interface to listen on a certain drive letter, and then parses the ISO9660 filesystem structures on a CD to provide file access.

Installing a network redirector requires the drive you want to redirect to be before LASTDRIVE, and it prevents any access to that drive letter to get into the FAT / block device layer. You can hide a drive supported by FAT/block-device-driver by "redirecting" this drive to somewhere else, most likely a network drive. On the other hand, the block device layer is completely inaware of redirected drives, so if you have two partitions, getting C: and D: as drive letters, NETDRIVE will get E: as drive letter, even if E: has already been redirected on at the redirector layer. (for example using ethdosfs or mscdex). Unless you load a dummy block device driver, you can not create "holes" between drive letters assigned to block device drivers.

You might be able to use DRIVER.SYS as "dummy block device driver" to shift drive letters, e.g. by creating a "duplicate" of drive A:, which is latter hidden using MSCDEX.

Reply 31 of 196, by Jo22

User metadata
Rank l33t++
Rank
l33t++

^There was technically also short-lived DOS 4, with its installable file system (IFS). Unlike the other versions, it was not limited to FAT per se. It was a very interesting concept, I think.

https://en.wikipedia.org/wiki/Installable_File_System
https://www.os2museum.com/wp/dos/dos-4-0/

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 32 of 196, by ivdimkra

User metadata
Rank Newbie
Rank
Newbie
mbbrutman wrote on 2023-12-12, 21:55:
ivdimkra wrote on 2023-12-12, 14:21:

I'm testing netdrive server on linux (ubuntu). Works fine, but can i run netdrive serve like a daemon, without terminal commands input ? I wish to start it from systemd service unit ..

I'll get that added.

At the moment I use it in the background, but I run it under "screen" so that I can just re-attach as needed to look at it. I was assuming that I would need debug info from it for a while so I didn't think about adding a true daemon mode.

Thanks!
On my Ubuntu 22.04 netdrive create command generates empty images:

$./netdrive create hd 64 FAT16B mydisk.dsk
mTCP NetDrive by M Brutman (mbbrutman@gmail.com) (C)opyright 2023, Version: Dec 10 2023

Specified MB: 64, Filesystem: FAT16B
Bytes per sector: 512, Sectors: 131072, Data sectors: 130527, Cluster size: 2
Reserved sectors: 1, FAT copies: 2, Sectors per FAT: 256
Root directory entries: 512, Sectors for root directory: 32

$ xxd -l 512 mydisk.dsk
00000000: eb3c 904e 4554 4452 4956 4500 0202 0100 .<.NETDRIVE.....
00000010: 0200 0200 00f8 0001 0000 0000 0000 0000 ................
00000020: 0000 0200 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

Works fine with images created with mkdosfs tool:

$ mkdosfs -F 16 -C mydisk.dsk 65536
$ xxd -l 512 mydisk.dsk

00000000: eb3c 906d 6b66 732e 6661 7400 0204 0400 .<.mkfs.fat.....
00000010: 0200 0200 00f8 8000 2000 0800 0000 0000 ........ .......
00000020: 0000 0200 8000 29da 6429 674e 4f20 4e41 ......).d)gNO NA
00000030: 4d45 2020 2020 4641 5431 3620 2020 0e1f ME FAT16 ..
00000040: be5b 7cac 22c0 740b 56b4 0ebb 0700 cd10 .[|.".t.V.......
00000050: 5eeb f032 e4cd 16cd 19eb fe54 6869 7320 ^..2.......This
00000060: 6973 206e 6f74 2061 2062 6f6f 7461 626c is not a bootabl
00000070: 6520 6469 736b 2e20 2050 6c65 6173 6520 e disk. Please
00000080: 696e 7365 7274 2061 2062 6f6f 7461 626c insert a bootabl
00000090: 6520 666c 6f70 7079 2061 6e64 0d0a 7072 e floppy and..pr
000000a0: 6573 7320 616e 7920 6b65 7920 746f 2074 ess any key to t
000000b0: 7279 2061 6761 696e 202e 2e2e 200d 0a00 ry again ... ...
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.

Reply 33 of 196, by Mu0n

User metadata
Rank Member
Rank
Member

I'm grateful for this great new utility!

I tried it with a use case close to heart - using it to get access to cdrom iso images through a network drive. I assigned a netdrive to a .dsk containing a bunch of iso files, then used SHSUCDX to mount it to yet another virtual drive and played a fmv heavy game just to see how it would perform. I used Cyberia since I remembered it loaded quite a lot from the disc in the fmv heavy gameplay from back in the day. It performed really well with no visible hiccup. PC used: a WeeCee which comes standard with an ethernet port.

if it could straight up mount a .iso file as a drive, it would save a step but I'm happy as is to edit my .dsk files (it's quite straightforward with WinImage).

Attachments

  • aaacyberia.png
    Filename
    aaacyberia.png
    File size
    319.54 KiB
    Views
    1388 views
    File license
    Public domain

1Bit Fever Dreams: https://www.youtube.com/channel/UC9YYXWX1SxBhh1YB-feIPPw
DOS Fever Dreams: https://www.youtube.com/channel/UCIUn0Dp6PM8DBTF-5g0nvcw

Reply 34 of 196, by mtest001

User metadata
Rank Member
Rank
Member

This is so neat!

I don't normally spend a lot of time under DOS but I'm happy to know that this solution exists if one day I need it....

/me love my P200MMX@225 Mhz + Voodoo Banshee + SB Live! + Sound Canvas SC-55ST = unlimited joy !

Reply 35 of 196, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
mkarcher wrote on 2023-12-13, 07:26:
MSCDEX is not a DOS block device driver and does not influence DOS driver device letter assignment. In DOS, there are two ways i […]
Show full quote
Yoghoo wrote on 2023-12-12, 14:42:
mbbrutman wrote on 2023-12-12, 14:32:

Did you load mscdex to get the drive letter before loading the device driver?

Tried it before and after loading mscdex. In both cases it will take drive letter E:. So it's overwriting the assigned drive for my CD when mscdex is already loaded and was assigned drive letter E:.

MSCDEX is not a DOS block device driver and does not influence DOS driver device letter assignment. In DOS, there are two ways in which you can install a handler for a drive letter:

  • The first one is to provide a block device driver. This kind of driver can read (and possibly write) sectors of a (possibly virtual) disk. DOS then adds its FAT driver on top of this driver so that you can access files on the drive. You can not teach DOS any new kind of file system this way. The block device driver does not get any clue about opening and closing files. It does not deal with file name. The only thing it deals with is sectors. Drive letters are assigned to block devices starting at C:, floppy drives do not count, they get the dedicated A:/B: letters; every partition on BIOS-supported hard disks is a different "block device". There is no way of assigninig specific letters to block drivers.
  • The second one is to install a hook for opening files on a specific drive letter. This code path is called the "network redirector", as this way of providing a virtual drive allows to redirect the open call (and if it succeeds, also the read/write/sync/close calls) to somewhere else, e.g. a network server. When installing a redirector, you can specifify which drive letter you want to listen to. If a file on that drive is going to get openend, DOS will call the redirector for this drive instead of the DOS-integrated FAT driver. You can use the network redirector interface to implement network file access (the DOS LANMAN client uses this interface, as does the VLM version of the Novell client, or does ETHDOSFS), or to implement file systems that the DOS kernel does not understand. MSCDEX is a "ISO9660 filesystem driver" that uses the network redirector interface to listen on a certain drive letter, and then parses the ISO9660 filesystem structures on a CD to provide file access.

Installing a network redirector requires the drive you want to redirect to be before LASTDRIVE, and it prevents any access to that drive letter to get into the FAT / block device layer. You can hide a drive supported by FAT/block-device-driver by "redirecting" this drive to somewhere else, most likely a network drive. On the other hand, the block device layer is completely inaware of redirected drives, so if you have two partitions, getting C: and D: as drive letters, NETDRIVE will get E: as drive letter, even if E: has already been redirected on at the redirector layer. (for example using ethdosfs or mscdex). Unless you load a dummy block device driver, you can not create "holes" between drive letters assigned to block device drivers.

You might be able to use DRIVER.SYS as "dummy block device driver" to shift drive letters, e.g. by creating a "duplicate" of drive A:, which is latter hidden using MSCDEX.

MSCDEX has a switch to assign a specific drive letter /L:x

Reply 36 of 196, by mbbrutman

User metadata
Rank Member
Rank
Member

It's not empty, it just doesn't have boot code in the first sector. It will mount using DOS and Linux and there will be no files or volume label on it.

Last edited by mbbrutman on 2023-12-13, 23:09. Edited 1 time in total.

Reply 37 of 196, by Yoghoo

User metadata
Rank Member
Rank
Member
mbbrutman wrote on 2023-12-13, 15:44:

It's not enjoy, it just doesn't have boot code in the first sector. It will mount using DOS and Linux and there will be no files or volume label on it.

True, but if a more compatible boot code was used during the creation of the image file with NetDrive it would be more compatible with external (Windows) tools. You can't open an image file created by NetDrive with 7-zip or PowerISO for example. If you reformat that image file (after mounting it with OSFMount or so) you can use those tools to open and manipulate those images. It also still works with NetDrive. Not necessary of course as there is a workaround but would be a nice feature request.

Reply 38 of 196, by mkarcher

User metadata
Rank l33t
Rank
l33t
maxtherabbit wrote on 2023-12-13, 14:04:

MSCDEX has a switch to assign a specific drive letter /L:x

That's well known. MSCDEX redirects file access to a specific drive letter using the functionality in the DOS kernel intended for network mapped drives. You can redirect any drive letter you want (unless it is past LASTDRIVE). Most tools implemented using the network drive technology allow specifying an arbitrary drive letter.

On the other hand, NETDRIVE is a DOS device driver, and DOS device drivers can not choose the letter they provide, instead DOS assigns letters sequentially to device drive. No block device driver allows setting the drive letter.

Reply 39 of 196, by maxtherabbit

User metadata
Rank l33t
Rank
l33t
mkarcher wrote on 2023-12-13, 20:32:
maxtherabbit wrote on 2023-12-13, 14:04:

MSCDEX has a switch to assign a specific drive letter /L:x

That's well known. MSCDEX redirects file access to a specific drive letter using the functionality in the DOS kernel intended for network mapped drives. You can redirect any drive letter you want (unless it is past LASTDRIVE). Most tools implemented using the network drive technology allow specifying an arbitrary drive letter.

On the other hand, NETDRIVE is a DOS device driver, and DOS device drivers can not choose the letter they provide, instead DOS assigns letters sequentially to device drive. No block device driver allows setting the drive letter.

Yes, I know. Just pointing out the switch because you didn't mention it and the guy who was struggling with the issue doesn't seem to know about it