I should mention that I have enabled netBUI in windows and I have found a diagnostic utility for this chipset, the utility detects the card fine in a command prompt in Windows but it doesn’t detect in DOS.

Both should be doable individually (possibly with a different network card), but afaik these things do not "stack" well - i.e. you'd need to copy the disc image off the network before mounting it. I'd recommend sinking more time into this only if that's acceptable.

I am 100% on board with sinking more time into this, that’s the plan. That was the point of this hobby machine 😀. Although if someone knows the answer, that works too.!!

There are DOS drivers for RTL8169: ODI and NDIS2.
I've successfully used it with mTCP, using the ODI driver + ODIPKT.
But for SMB, you need Microsoft Network Client version 3.0 for MS-DOS - which uses NDIS2.

Iirc, xmsdsk can be dynamically resized, and can serve as your 'local' sink for mounting iso files,such as can be done with the shsucdx package.

If you have lots of UMB area to burn, you can leverage an empty drivespace3 cvf, and scandisk, to cut back on the amount of xms you burn. (It depends on what is on the iso, how well it will compress.) This would just be 'frosting' on the cake, but could also be done.

Essentially, you need some way to pull data from a network source. The full smb stack for dos is very memory hungry, and will hamstring gaming terribly. If you go this route, you would need the 'networking suppliment for dos' disk set, and ndis drivers for your network card.

A potentially better solution, would be just a minimal packet driver, and a tftp or ftp client.

Since smb 1.0 lacks good oplock support (and thus does not seek to arbitrary parts of a file well), pulling the full .iso is recommended.

Enter xmsdsk.

When run from a batch file, xmsdsk can be resized dynamically, up to 2gb in size. The ramdisk that results has a fat16 structure, which is why it tops out at 2gb. (It's also why it can work with drvspace cvf containers...)

So, use a batch file to resize the ramdisk to the needed size, then tftp/ftp/smb file copy the .iso to it, then use SHSUCDHD from the full shsucdx package to mount it.

Call your game, and play for awhile.

Quit, and the batch 'should' resume, unmount the .iso, resize the ramdisk to 0, then return to command prompt.

This way, all you need in umb is the minimal packet driver for the tftp, shsucdhd, and xmsdsk.

Wow, some great information here, thanks all.

A simpler option you could consider - although it might not be suitable in all cases - would be mounting .iso file(s) on whatever machine is hosting the server, and then sharing the contents as regular folders. Depending on what your server's operating system is and whether it's running on a physical or virtual machine, you could have a number of .iso files mounted at once and a whole lot of separate shares with unique names, you could have them all in one share (if you don't have software that expects something to be in a particular location on the drive like the root directory), or you could just have a single share pointed at a directory where you mount/unmount different .iso files if you want something like changing discs.

For example I run Linux, and run Windows NT Server in a VM which has a single share for the virtual CD drive, and I tell VirtualBox to change which .iso file is mounted in the virtual CD drive and of course a client using that share can see whatever is in the .iso file I chose. In another case I use VirtualBox's shared folders (but the same should be possible with network shares) to share a directory which has about a dozen .iso files mounted under it, because the software running in the VM doesn't care that its files aren't in the root directory, probably because it was designed to run from a network. Maybe DOS software is less likely to work that way though.

Again, the problem is with opportunistic locking, or rather, its lack there of, with SMB1.0

This mostly manifests in issues with ensuring data integrity on writes, but also causes problems with caching on reads, with large files.

https://www.dataaccess.com/kbasepublic/files/ … ase_pdf_fmt.pdf

In a nut-shell, SMB 1.o does a very poor job of reading or writing files in a random-manner from a client. The technology was not intended to host very large files over the network (in the case of SMB1.0), and this results in broken reads, cache misses, generally very poor performance, and in the case of writes, data losses. The technology very much intends for the client to pull THE ENTIRE FILE, and CACHE IT LOCALLY, then upload THE ENTIRE FILE when you are done with modifying it, in the case of SMB1.0

This is not suitable for the purposes outlined with mounting the image across the network, as described. (It works acceptably well with SMB 2.0 and SMB 3.0-- such as when used to host disk images for hacked game consoles, or disk libraries across the LAN on modern versions of windows--, because of improvements in how the protocol works, but DOS's implementation of SMB is **NOT** SMB 2.0 or 3.0 !!!)

This is why the OP will be much better suited pulling the full .ISO into a ramdisk (to function as a local cache), then mounting it there, and then purging after they are done playing.

(NOTE-- the linked article discusses disabling oplocking for database files, and how to do this on NT and newer versions of windows. Note, that the SMB 1.0 implementation used by dos, and the CIFS implementation used by windows NT and newer, ARE NOT THE SAME PROTOCOL. The PDF is more geared toward the CIFS variant, while we are discussing the old, "ACTUALLY REAL SMB1.0" found in DOS clients.)

https://www.upguard.com/blog/cifs-vs-smb

Note that "Larger Files" support, is one of the selling points for the newer CIFS dialect used by win9x and pals. The DOS network suppliment does not speak CIFS. It speaks SMB1.0

Since this basically tabulates out to "You really should just pull the whole damn file and cache it locally" no matter which route you take, coupled with "The SMB1.0 stack is bloated and huge, and takes up gobs and gobs of conventional memory", you end up with the suggestion I and others hit on: Use a simple packet driver and a simple file transfer client to pull the files, then mount them-- or use one of the more modern remote-drive protocol service providers using such a simple packet driver arrangement.

Either one will give you a better experience.

I'd like to point out that OP didn't specify any protocol/fs, so things like NFS or Novell Netware are still on the table. Though I have little experience with both, at least within DOS, but maybe one of you guys has an idea how appropriate they'd be here?

wierd_w wrote on 2024-03-29, 08:26:

Again, the problem is with opportunistic locking, or rather, its lack there of, with SMB1.0

This mostly manifests in issues with ensuring data integrity on writes, but also causes problems with caching on reads, with large files.

I think you must be addressing my suggestion since nothing else has been suggested since your last post, but your concern seems to presume that the filesystem inside the .iso file contains large files, which isn't necessarily a given. If you mount an .iso file containing files which aren't "large" on the server, share the mounted folder as a share, then the client only sees the non-large files inside and has no idea they're in a large .iso file.

Since this basically tabulates out to "You really should just pull the whole damn file and cache it locally" no matter which route you take, coupled with "The SMB1.0 stack is bloated and huge, and takes up gobs and gobs of conventional memory", you end up with the suggestion I and others hit on: Use a simple packet driver and a simple file transfer client to pull the files, then mount them-- or use one of the more modern remote-drive protocol service providers using such a simple packet driver arrangement.

Maybe since OP's machine runs Windows 98 SE, it's new enough to have enough RAM to store an entire .iso file (possibly compressed), but with the 64MB of RAM in the machine I was last doing this with, if I'm pulling the entire .iso file anywhere it'd need to be onto the hard drive! 😁

elszgensa wrote on 2024-03-29, 09:53:

I'd like to point out that OP didn't specify any protocol/fs, so things like NFS or Novell Netware are still on the table. Though I have little experience with both, at least within DOS, but maybe one of you guys has an idea how appropriate they'd be here?

I don't really know. All I know is that in the olden days, you might put a physical CD-ROM in a physical CD drive in a physical server, share that CD drive over the network, and then some client without much RAM would connect and get to access the files and I'd just be glad it could get to the files at all 😁 Quite recently I did the same with a virtual Windows NT Server and a DOS machine running Microsoft Client 3 (I think) and it seemed to perform well enough for my liking when I installed some software off it. Perhaps it would be terrible if I was playing a game that wanted to play video off the mounted drive or something, but on the other hand the machine in question was from an era when I had a double speed CD-ROM drive, so probably contemporary games didn't have much expectation about read speeds from CDs anyway. OP may have a much newer machine and newer games with different expectations.

doshea wrote on 2024-03-29, 11:18:

I think you must be addressing my suggestion since nothing else has been suggested since your last post, but your concern seems […]
Show full quote

wierd_w wrote on 2024-03-29, 08:26:

Again, the problem is with opportunistic locking, or rather, its lack there of, with SMB1.0

This mostly manifests in issues with ensuring data integrity on writes, but also causes problems with caching on reads, with large files.

I think you must be addressing my suggestion since nothing else has been suggested since your last post, but your concern seems to presume that the filesystem inside the .iso file contains large files, which isn't necessarily a given. If you mount an .iso file containing files which aren't "large" on the server, share the mounted folder as a share, then the client only sees the non-large files inside and has no idea they're in a large .iso file.

Since this basically tabulates out to "You really should just pull the whole damn file and cache it locally" no matter which route you take, coupled with "The SMB1.0 stack is bloated and huge, and takes up gobs and gobs of conventional memory", you end up with the suggestion I and others hit on: Use a simple packet driver and a simple file transfer client to pull the files, then mount them-- or use one of the more modern remote-drive protocol service providers using such a simple packet driver arrangement.

Maybe since OP's machine runs Windows 98 SE, it's new enough to have enough RAM to store an entire .iso file (possibly compressed), but with the 64MB of RAM in the machine I was last doing this with, if I'm pulling the entire .iso file anywhere it'd need to be onto the hard drive! 😁

No, I am asserting that an .iso file is itself, a large file.

Some games are not satisfied with just a folder with the correct files inside, and check the volume label, and if mscdex is loaded. (Daggerfall being one such beastie)

It is perfectly doable to use shsucdhd to mount an entire .iso file and emulate a cdrom drive with mscdex, and do it 'cheaply' (ram usage wise).

You just should not do that over smb, because smb does not like random file accesses.

I think you guys are overthinking it.

What's a "large" file?
The only reasonable definition is: larger than MAXINT for 32-bit, ie. 2 GB or 4 GB.
CD images are 650 MB, DVD images are larger, but was there any DOS software distributed on DVD?

File locking is another non-existent problem.
It only occurs when multiple processes/clients are trying to simultaneously WRITE to the same file.
But ISO images are read-only!

Heavy memory usage of that DOS SMB client may be a problem, true.
Not always, though: CD-ROM games usually use a 32-bit extender, which greatly reduces conventional memory usage.

Overall, it may turn out that the only real problem is:
CD AUDIO TRACKS.
It's often the only option for background music, and I'm afraid there's no feasible way to play them other than a real CD-ROM drive.

No, that is not correct.

Oplocks are intimately tied to the caching system, and are how smb assures concurrency with the locally cached data in its buffers vs what is on the server's drives.

Oplocking allows the client to be significantly less chatty.

See the FEATURES section.

https://en.m.wikipedia.org/wiki/Server_Message_Block

It is NOT exclusive to writes!

See also, this chunk,

wikipedia wrote:

Network designers have found that latency has a significant impact on the performance of the SMB 1.0 protocol, that it performs more poorly than other protocols like FTP. Monitoring reveals a high degree of "chattiness" and a disregard of network latency between hosts.[13] For example, a VPN connection over the Internet will often introduce network latency. Microsoft has explained that performance issues come about primarily because SMB 1.0 is a block-level rather than a streaming protocol, that was originally designed for small LANs; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the TCP window size is not optimized for WAN links.[14] Solutions to this problem include the updated SMB 2.0 protocol,[15] Offline Files, TCP window scaling and WAN optimization devices from various network vendors that cache and optimize SMB 1.0[16] and 2.0.[17]

The maximum requestable block size is 64kb, which results in A LOT of chatty traffic when serving large files.

The protocol is really just not designed for it, and is meant to transmit small files. The link quickly saturates with large files due to the protocol transport control message overhead. With many devices in a segment all being equally chatty, it gets a lot worse.

This is *the reason* for oplocking, as it allows clients to cache transactions and talk a whole lot less.

SMB2/3 further improves on this, by no longer being restricted on the 64k element size, by being 32 or 64bit data aware.

SMB2 includes support for symbolic links. Other improvements include caching of file properties, improved message signing with HMAC SHA-256 hashing algorithm and better scalability by increasing the number of users, shares and open files per server among others.[13] The SMB1 protocol uses 16-bit data sizes, which amongst other things, limits the maximum block size to 64K. SMB2 uses 32- or 64-bit wide storage fields, and 128 bits in the case of file-handles, thereby removing previous constraints on block sizes, which improves performance with large file transfers over fast networks.[13]

Yes, there may be some issues with PERFORMANCE.
But probably not worse than a real CD-ROM, with its slow seek.

Definitely no risk to DATA INTEGRITY here, though.

Oh no, data integrity is an issue (as far as the client sees, anyway...)

Smb has a timeout window in which it will just hang up the connection if it cannot communicate round trip within.

This is an event that service providers like the afore-mentioned shsucdx package is not equipped to handle, and it acts like a medium error when it occurs. The whole 'cdrom' becomes unreadable during gameplay because the connection reset, and the file handle becomes orphaned/stale.

It's just not a smart thing to try.

Use a transport that is more appropriate/robust.

Really.

I'm trying it right now...

ISO image on a modern server, with Linux and Samba

client is 386DX-40
Microsoft Network Client version 3.0 for MS-DOS
SHSUCDHD+SHSUCDX

Seems to work fine...
I can see the ISO as a drive letter, and copy files onto the local HDD using Volkov Commander.

How to create the error?

OK, the setup from the previous post does indeed hang randomly during long copy operation.

So I tried another approach: "mount -o loop filename.iso dirname" at the server side.
This time no problem at all.

wierd_w wrote on 2024-03-29, 16:11:

wikipedia wrote:

Network designers have found that latency has a significant impact on the performance of the SMB 1.0 protocol, that it performs more poorly than other protocols like FTP. Monitoring reveals a high degree of "chattiness" and a disregard of network latency between hosts.[13] For example, a VPN connection over the Internet will often introduce network latency. Microsoft has explained that performance issues come about primarily because SMB 1.0 is a block-level rather than a streaming protocol, that was originally designed for small LANs; it has a block size that is limited to 64K, SMB signing creates an additional overhead and the TCP window size is not optimized for WAN links.[14] Solutions to this problem include the updated SMB 2.0 protocol,[15] Offline Files, TCP window scaling and WAN optimization devices from various network vendors that cache and optimize SMB 1.0[16] and 2.0.[17]

I don't doubt that that is all true (and in fact know some of it's true from working on Samba), but in my use case:
- SMB 1.0 can feel free to disregard the latency because I'm not sending traffic over the Internet, just over a LAN like they designed it for
- I'm using NetBIOS frames (aka NetBEUI) rather than TCP, not that it really matters since I'm on a LAN
- I'm pretty certain I don't have any SMB signing happening; there are still people in the 2020s who aren't using it and I'd be surprised if any DOS clients support it

I think the way I'm using SMB 1.0 - and suggested others could use it - is exactly as it was expected to be used: with files much smaller than your average .iso file, and over a LAN. Okay, I didn't explicitly say people should only use what I suggested over a LAN, I just assumed nobody has their personal NAS for their retro device at another site or in the cloud!