• Please review our updated Terms and Rules here

PC "Tweeners"

Talk about looooooong-winded... The Panasonic device driver appears to be 100 times simpler to set up and get running than either of those other two. So, if you're only looking to get your FAT32 USB flash drives, etc., running under DOS you can take the easy way out. You know that it can't be too difficult if I got it running in under 10 minutes! :)
 
One word of warning--at least with the Panasonic drivers, the system is unaware of "hot plug" devices. That is, don't expect it to see change in devices (e.g. USB flash, etc.). The device must be present at boot time. Perhaps that's changed, but that's what I found when I tried the drivers.
 
You are correct. Nothing's been changed. Even if you remove the device that was present at boot time and then (immediately) reinsert it it will not be recognized. As you stated, it must be present at boot time. But, since DOS boots in milliseconds on a fast Pentium with a SS drive... :)
 
It would seem to be simple to add an IOCTL call or entry point to say "look again for new media", but, to the best of my knowledge, the source to that driver was never published.
 
Thanks for the suggestions. If I can load files onto a USB drive from a DOS environment and transfer them to a machine where I can burn them to DVD I've solved the main problem.

Apart from the doorstops kicking around here I have two DOS machines: one is a '586 running DOS 6.22 / WFW 3.11 and the other a PII running Novell DOS 7 - mostly out of curiosity. No need for peripherals: Got parallel ports on both and lots of parallel printers. Serial mouse on the 586, PS2 on the PII.

I haven't found a way to make either one drive a CDRW. Read, yes, write, no. I have Adaptec burning software but the drives it knows about I don't have, and they were SCSI back in those days anyway. I gave away my Philips CDRW 800 some time ago. Duh.

So read floppy to disk, write to USB, transfer USB to machine with DVD-write capabilities is the intended workflow. This after I burned up a drive using one of those USB drive-controllers. A quiet pop, a small puff of smoke, and goodbye Maxtor... Damn!

-CH-
 
It may be convenient but I'm not too thrilled with the Windows/DOS interface, even with mTCP. FTP is cumbersome and slow with this method. I guess I'm just spoiled with the ease presented by Windows Explorer between two Windows machines. KISS

If you got any suggestions or recommendations re:Windows/DOS network products and interfaces I'm all ears. I'm currently using the DOS UMB method because it's easy, fast and *simple*.
 
Stone said:
I'm currently using the DOS UMB method because it's easy, fast and *simple*.
Click to expand...

UMB? Did you mean SMB?

When one of my endpoints is a system not capable of running Windows, I've found there is no easier or faster solution than mTCP. Fits on a floppy, and I boot right into the FTP server, then a nice FTP GUI client like FileZilla facilitates "drag'n'drop" between the two systems.
 
Trixter said:
UMB? Did you mean SMB?

When one of my endpoints is a system not capable of running Windows, I've found there is no easier or faster solution than mTCP. Fits on a floppy, and I boot right into the FTP server, then a nice FTP GUI client like FileZilla facilitates "drag'n'drop" between the two systems.
Click to expand...
My bad... I meant DOS USB :smile:

Besides, I get lots of FTP transfer errors whenever I use mTCP due to *its (DOS')* 8.3 file name limitation. It seems FileZilla (and other FTP programs) can't transfer any files to the DOS machine if the name isn't in the 8.3 format. That sucks! At least when I transfer those files with non 8.3 names via a USB stick DOS can successfully concatenate the name and complete the transfer. So, what good is FTP that can only transfer *some* files to the DOS machine? Is there an FTP solution for that?
 
Stone said:
It seems FileZilla (and other FTP programs) can't transfer any files to the DOS machine if the name isn't in the 8.3 format. That sucks!
Click to expand...

An automatic rename would indeed be nice. Whether this is the responsibility of the client or the server is debatable, as there are pros and cons for either side performing the namespace translation.

AFAIK there are no USB storage solutions for a system with only 8-bit slots and/or drivers that work on CPUs under 80186, but I would be happy to be corrected (preferably with links to hardware that can be purchased).
 
It hardly seems fair to blame FTP (any flavor) for the underlying faults of the OS ... DOS uses the 8.3 format. And it is not case sensitive. That is part of the charm of DOS.

No file transfer program is going to get around that problem. The best you can ask for is some sort of warning when a file can not be transferred, or some sort of automatic name munging. And the second is problematic because people will complain about the way the names are altered no matter what you do.
 
What's the mechanism that 'munges' the name(s) when a long name file is viewed via the USB stick? It's the same OS that won't transfer it that is able to read the name as a munged name.
 
mbbrutman said:
some sort of automatic name munging....is problematic because people will complain about the way the names are altered no matter what you do.
Click to expand...

I wouldn't complain. The typical use case for this is transferring .zip files with long filenames over to an older system. I don't care what the .zip name is, because all I care about are the files inside it.

If I was designing this, I would put it into the mTCP FTP server as a user-configurable option to automatically create an 8.3 munged filename when it receives a name that doesn't fit those standards.

Might be fun to come up with a munging algorithm :) For example, first remove all spaces, then use a mask of "OOOOO~XX.OOO" where OOOOO=original first five chars and extension, and XX is 0-9,A-Z variable that starts counting from "00" through "ZZ". And, the FTP server could check to see if an existing name is taken before committing to it to avoid collisions (in case the FTP server was restarted between transfers that would result in overwriting a different file with the same name).
 
Well, if the long-name APIs are available, such as through DOSLFN, long names aren't really an issue. DOSEmu for Linux has its own name-munging code in it. Sometimes the translations are anything but clear. It's worsened by the fact that *nix differentiates between upper and lower-case (as to *nix-interface ftps). I've never tested to see how far back in DOS versions that DOSLFN will work.

It's like trying to fit a gallon of whiskey into a fifth bottle, in any case.
 
DOS munges the names automatically. So, what are we missing?

I wouldn't complain, either.

Mike... have you got anything planned for this weekend? :)

Thanks in advance.
 
Stone said:
DOS munges the names automatically. So, what are we missing?
Click to expand...

Really? What version of DOS has long file name support built into it?

The DOS that people extract from Win 95 or Win 98 might have long file name support, but that's not a version of DOS that was ever sold as DOS. Legitimate PC DOS and MS DOS versions do not have long file name support.
 
Right, Win 98 DOS. But it munges the file names to 8.3 just like DOS 6.22 does. No long file names.

It's got fat32 support as well so it does quite nicely with the USB flash drives.
 
I ran some quick experiments and I'm going to correct myself from above. DOS is not doing any filename translation between short names and long names. Win 98 is doing that.

All of the MS operating systems that support longer filenames on a FAT filesystem use hidden directory entries to store the long filenames, while using standard 8.3 filenames to remain compatible with DOS. So if you have an OS that supports long filenames, it knows to look for the hidden directory entries.

Want to try an experiment? Boot a Win 98 DOS startup disk. Try to create a long filename. You can't ... Nor can you see the long filenames on a filesystem. All DOS ever sees is the short names, which are stored in the FAT.

So back to the original problem. DOS does not support long filenames. Long filenames are hacked onto FAT filesystems by OSes like Win 9x, NT, etc., but there is no capability in DOS to do it. There is a third party utility called DOSLFN but I hear it's not terribly stable. (See http://www.freedos.org/software/?prog=doslfn )
 
You must log in or register to reply here.
Back
Top