PDA

View Full Version : PC "Tweeners"



Chuck(G)
January 26th, 2016, 10:12 PM
I couldn't find a thread on the subject of what old PCs make good "tweener" systems. Since older systems can be had for little more than junk prices, this might be of some help.

I'll kick it off with a test of the HP Vectra VL600.

Produced around 2001, this has a FIC KC-19+ motherboard.
Usual 2 serial + parallel + usb for the time.
Requires an AGP for display (I think HP furnished a low-end Matrox board).
Chipset is Intel 820, which means RIMM/RDRAM for memory. Fortunately, that stuff is cheap nowadays (I paid $10 for 1GB of 800MHz RIMM).
Slot 1 P3 CPU with 133MHz system bus. I installed a Socket 370 1.4GHz Tualatin P3 with a Powerleap Slocket I had.
2 floppy controller, capable of FM and MFM, and supports 128 byte MFM (surprise!).
Sound is Crystal CS4622.
...and 2 ISA slots, 4 PCI slots

BIOS updates and manuals are available from the FIC ftp site (ftp://ftp.fic.com.tw)

Overall, a pretty snappy setup; I loaded mine up with Win98SE, WinXP and Xubuntu 14.04 and a Linksys PCI wireless card.

glitch
January 27th, 2016, 04:56 AM
I use old industrial PICMG systems. Right now I have:

1x 20-some slot PICMG rackmount chassis
* P4 single board computer, 1 GB RAM, 1.8 GHz IIRC
* ungodly number of ISA slots
* onboard Ethernet
* onboard USB
* onboard AGP graphics
* internal 3.5" floppy and CD-RW

1x 4-slot ISA only chassis, my portable test rig
* 1 GHz P3 single board computer, 512 MB RAM
* PC/104+ SATA mezzanine controller, attaches directly to CPU board
* Adaptec AHA-1522A for floppy + SCSI
* EPROM burner card lives in this one
* onboard Ethernet
* onboard AGP graphics
* internal 3.5" floppy

1x 6-slot PICMG chassis, this one lives on the workbench
* 600 MHz P3 single board computer, 768 MB RAM
* 2 ISA + 2 PCI + 2 combo PICMG slots
* usually has a PCI Adaptec card
* FireWire/USB 2.0 PCI combo card
* onboard Ethernet
* onboard PCI graphics

All three dual boot Slackware Linux and MS-DOS. In addition to the usual cards installed, I can also pull the CPU board and replace it with "other stuff" -- for instance, I have a 486 CPU board I often use when dealing with old MFM or ESDI drives. I think PICMG is the optimal way to go for a utility PC, since you can always upgrade the internals, and the bigger boxes provide a *ton* of ISA slots.

Stone
January 27th, 2016, 05:29 AM
My tweener runs DOS 3.3, DOS 6.22, WIN98SE DOS (for FAT32 with a DOS command prompt on a 2 GB DOM), WIN ME, WIN XP and anything else I care to have it run. These all run on a machine with a 233 MHz CPU on a board with four PCI and three ISA slots as well as SIMM and DIMM slots. It has two mobile hard drive racks in two of the 5" bays so it's simple to switch drives (and OSes) in an instant. It supports USB in DOS so I can access USB flash drives while running DOS. It has both floppy drives, is on my network and hosts a dot matrix printer for the rest of the network via its parallel port. In DOS mode it's configured with two 32 MB RAM Drives which make for excellent DOS software testing stations.

vwestlife
January 27th, 2016, 06:12 AM
I have a Compaq Deskpro SB with a Pentium III that is new enough to run Windows XP, but old enough to have support for dual floppy drives, including 5" drives. Most machines from the Pentium 4 era and newer only support a single floppy drive, and often only support a 3" 1.44 MB drive.

SomeGuy
January 27th, 2016, 06:40 AM
Well, in my opinion, an ideal tweener would:

-Have any Pentium, K6, or Athlon era CPU
-Have a generic AT or ATX case
-Have BIOS support for *two* real, internal floppy drives.
-Have Ethernet Networking (easy to add)
-Have Windows 95 OSR2 or 98SE as the primary OS for easy DOS access (ME/2000/XP are more difficult)
-Have USB ports for flash drives.
-Have at least one ISA slot and plenty of additional slots (AGP/PCI)
-Ideally the FDC should support FM encoding, but that is rather uncommon and hard to tell just by looking.
-The motherboard should use a coin cell CMOS battery instead of a Dallas or Odin integrated clock/battery chip.

Funny thing, my "regular" computer, a KT7A with Mobile Athlon XP meets most of those specs. But the 1.2mb 5.25" and MFM-only FDC are a bit limiting. So I wind up using my old generic AT style desktop 286 as a "tweener", since that has FM support, a proper 360k drive, and also runs my Transcopy card.

A while back I also got 5ABBA (ALI M1542/1543 chipset) a AMD K6-500 AT form motherboard and a AHA-1542CP to use for workbench testing. I did a double take after testing the AHA-1542CP when I noticed the motherboards on board FDC also passed all TESTFDC tests. That would potentially make a damn good "tweener" board.

Chuck(G)
January 27th, 2016, 09:40 AM
I'll add that I do have a stack of "tweeners" and had been using a Supermicro server board with 2GB and a couple of 1GHz SL4BS P3s. The interesting thing is that the Supermicro board is noticeably slower in XP than the single-processor FIC board. But the real deal-breaker was that the Supermicro FDC didn't do FM. It's all mounted in a rack, along with a 9 track tape drive, so basically, I sit down in front of it, pull out the keyboard drawer and settle down to work. For floppies, I had to pull out a separate system with an added Compaticard FDC.

Now that's finally handled. I'm working on a 5.25" drive bay replacement with two DC-37F connectors on it, so I can connect to either the onboard FDC or the Catweasel from the front of the system with any of my external drives.

The Win98SE partition boots to a command prompt, loads DOSLFN and HXDOS. I've never found any reason to run any older DOS versions on this setup.

SpidersWeb
January 27th, 2016, 10:18 AM
I have so many machines these days I keep just using "whatever" but the machine I built as a tweener is:

I used a Gateway 2000 case with 4x5.25" bays, motherboard is full size ATX but can't remember the model - pretty sure it's a Gigabyte branded model though.
- Pentium 166 MMX
- Diamond 3D Monster VooDoo 2 (might as well play some games with it!)
- 2 x IDE drives (I think 6GB and 2GB?)
- 5.25" 1.2MB Panasonic (good enough to write a quick 360 on a blank disk, as well as 720KB "DSQD" for the AT&T)
- 3.5" 1.44MB
- Syquest 200C (reads 44MB, 88MB and 200MB cartridges) SCSI
- Iomega Zip 100 SCSI
- PCI SCSI card
- Generic CDROM
- Dual Boot (using a great program called GAG) MS DOS 6.22 and Windows 98
- On the network, so I can drop files on it easily

I added a PCI USB card but it kept causing system instability, and being on the network negated the requirement so I gave up.

These days it tends to be primarily used to write custom 5.25" disks when I need something quick or for archiving floppy media with ImageDisk or similar. If I'm actually loading an older machine with software or need a terminal (UNIX etc) I actually grab a laptop from the pile, dump what I need via the network, then take it wherever and hook up the serial port.

For writing 360KB floppies I plan to keep for a long time, I actually use one of the XT's because they're networked up now.

krebizfan
January 27th, 2016, 11:13 AM
I have multiple Gateway Pentium-IIs setup to handle tweener style duties. Pair of floppies, USB card, cd writer, FX5200 video card (because it was cheap 10 years ago); the major difference is which removable cartridge drives are installed.

dosbox
January 27th, 2016, 11:27 AM
I never heard the term "Tweener" and I don't seem to understand what it means.

Chuck(G)
January 27th, 2016, 11:41 AM
I never heard the term "Tweener" and I don't seem to understand what it means.

Easy enough--a system that adapts new-style content to old-style equipment. For example, writing 9 track tapes from Internet-published .TAP files to boot your IBM S/360 setup.

krebizfan
January 27th, 2016, 11:43 AM
I never heard the term "Tweener" and I don't seem to understand what it means.

"Tweeners" are systems setup to aid in transferring data from a truly vintage system and a very recently manufactured system. A minimal tweener would have a real floppy controller and a range of old ports but also network or USB ports.

SomeGuy
January 27th, 2016, 11:45 AM
I never heard the term "Tweener" and I don't seem to understand what it means.
It is short for "an in between system" that lets one easily communicate between "modern" lobotomized hardware and various vintage systems. This is often required because the rectangular black pieces of Chinese sludge people call computers these days lack important features such as floppy drives, serial ports, etc and often can not be reasonably upgraded or expanded to include them.

Klyball
January 27th, 2016, 04:19 PM
i am using a picmg setup

core 2 duo e7600
4 gig ram
6 isa
6 pci
4 serial
2 parrellel
usb
lan
360k or 1.2m 5.25
and
720k or 1.44m 3.5
dvd

dos,win 95, win 98,xp and win 7
gpib to run hpdrive emulation
all-03 universal programmer

just can't get a mfm controller card to catch so i have a 486/586 SBC in a seperate set up

covers pretty much everything i need to do

SpidersWeb
January 27th, 2016, 06:15 PM
Oh yeah, for MFM/FDD duties - 386SX/25 in a very poor condition flip-lid style XT case, XT-IDE ROM (AT Version) and boots off a 20GB Seagate. It's nasty, but such a champion.
8 bit MFM controllers work side-by side with the IDE, only have to pull the IDE stuff if working with 16 bit gear.

gepooljr
January 27th, 2016, 06:18 PM
My "Tweener" is a Intel CA810E with a P3-850. DVD drive, Dual Floppy Drive running Win98SE. I've tested it with NetBSD and with Fedora Core 5. Runs very nicely with all the services to transfer data/media. I'm planning to put in an IDE to CF adapter once I finished unpacking from a recent move to Oregon.

billdeg
January 27th, 2016, 07:37 PM
I have posted this elsewhere, but my tweener is a Pentium III, generic system. I have added an 8" and 5 1/4" disk to the system. It hsd USB and CD too. I have a USB extension cable coming off the motherboard so I am attach USB devices to it without flipping around to the back. I run DOS 6 and Win 2000, dual boot. I've installed a Catweasel drive controller and I also use the motherboard's drive controller depending on the circumstances. Nice, simple, works.

I have others, but this definitely my go-to system for making disks, transferring files, etc.

I very much encourage everyone new to the hobby to build something like this a real time saver.

Unknown_K
January 27th, 2016, 08:57 PM
Anything with built in serial and parallel ports tends to work (some people love old Pentium 2/3 laptops for this reason). I use an old Thinkpad R52 for programming newer EPROMs via the USB port. Thinkpad A20 to A31 laptops are also nice since they have a built in floppy drive along with CDROM/DVD drive so archiving floppies is easy and portable. Older laptops are also nice since you can get PCMCIA adapters for almost anything (SCSI, firewire, flash disks, LS-120 drives, etc).

As far as PC's go I have everything from the first IBM PC to multi core multi GPU machines and everything in between.

clh333
February 4th, 2016, 04:11 AM
It supports USB in DOS so I can access USB flash drives while running DOS.

Okay, you got my attention. How do you run USB from DOS, and which version of DOS?

I have a similar rig (ASUS combination ISA and PCI, was once an HP Pavilion) and have heard it was possible but never found a way to drive USB devices from DOS. The box is currently running Novell DOS 7 but that can be scrapped any time. I also have MS-DOS 5, 6.22, Win 3.1, Win95, Wiin98 and XP as possible candidates.

Thanks for your reply.

-CH-

P.S. the BIOS on this board only supports one drive and so far hasn't liked any of the 5.25s I've tried to pair with it. 360, 1.2, nada.

Stone
February 4th, 2016, 05:11 AM
Okay, you got my attention. How do you run USB from DOS, and which version of DOS?Most later versions, I suspect. I'm using DOS 7.x but I don't think you'd have a problem with 5.x or 6.x.

http://www.techspot.com/community/to...der-dos.25953/ (http://www.techspot.com/community/topics/run-usb-devices-under-dos.25953/)

http://www.pcxt-micro.com/dos-usb.html

It's great -- I use it for flash drives on my tweener. I can't use my USB HDD though because it's NTFS but any FAT32 device is good to go with these two USB drivers. Yup! That's all it takes -- two drivers. And I'm able to load one of them high so my tweener is happy. :smile:

clh333
February 4th, 2016, 08:49 AM
Found the files on http://www.pcxt-micro.com/dos-usb.html. The first link is no longer active for the "moto hairu" driver. We'll give it a shot.

Thanks!

-CH-

krebizfan
February 4th, 2016, 09:03 AM
There are another two sets of USB drivers for DOS handling devices other than the storage that Panasonic wrote for. So it will be possible to use some printers, mice, etc, off the USB port under DOS.

No longer free: http://www.georgpotthast.de/usb/
Free: http://bretjohnson.us/

Stone
February 4th, 2016, 11:04 AM
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! :-)

Chuck(G)
February 4th, 2016, 03:24 PM
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.

Stone
February 4th, 2016, 03:37 PM
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... :-)

Chuck(G)
February 4th, 2016, 05:30 PM
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.

Stone
February 4th, 2016, 07:10 PM
The source is available for the Bret Johnson driver.

clh333
February 5th, 2016, 03:28 AM
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-

Chuck(G)
February 5th, 2016, 07:04 AM
I don't know--you still can't beat a NIC for convenience if your aim is data transfer.

Stone
February 5th, 2016, 08:27 AM
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*.

Trixter
February 5th, 2016, 09:16 AM
I'm currently using the DOS UMB method because it's easy, fast and *simple*.

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.

Stone
February 5th, 2016, 11:53 AM
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.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?

Trixter
February 5th, 2016, 12:56 PM
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!

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).

mbbrutman
February 5th, 2016, 01:27 PM
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.

Stone
February 5th, 2016, 01:37 PM
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.

Trixter
February 5th, 2016, 01:40 PM
some sort of automatic name munging....is problematic because people will complain about the way the names are altered no matter what you do.

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).

Chuck(G)
February 5th, 2016, 01:50 PM
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.

Stone
February 5th, 2016, 01:51 PM
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.

mbbrutman
February 5th, 2016, 05:34 PM
DOS munges the names automatically. So, what are we missing?

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.

Stone
February 5th, 2016, 06:45 PM
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.

mbbrutman
February 5th, 2016, 08:38 PM
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 )

Chuck(G)
February 5th, 2016, 08:46 PM
I routinely use Win98SE on FAT32 volumes with DOS LFN. I get long names. even in non-GUI (Boot to MS-DOS) mode as long as I use Int 21h AX=71xxh to make my calls per spec. There' also a long-to-short API (7160h, IIRC). At any rate Ralf Brown's list has details.

krebizfan
February 5th, 2016, 09:10 PM
The Lan Manager client for DOS would automatically do name mangling and turn long file names into 8.3 names. I believe some of the other DOS networking clients could do the same if attached to a long file name capable server.

I seem to remember that several FTP clients had options to automatically create 8.3 names to replace the longer names.

mbbrutman
February 5th, 2016, 09:13 PM
I routinely use Win98SE on FAT32 volumes with DOS LFN. I get long names. even in non-GUI (Boot to MS-DOS) mode as long as I use Int 21h AX=71xxh to make my calls per spec. There' also a long-to-short API (7160h, IIRC). At any rate Ralf Brown's list has details.

Does that work if you boot Win 98 from a floppy?

Either way, Win 9x DOS is the exception to the rule. No other DOS has LFN support.

clh333
February 6th, 2016, 03:18 AM
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.

Had no idea that solution existed. Thanks for the tip. I'll check it out.

Dealing with DOS 8.3 name restrictions: we used to use a little utility called RENAMEWIZ. Link here (http://download.cnet.com/RenameWiz/3000-2248_4-10257570.html)

-CH-

Stone
February 6th, 2016, 04:36 AM
I think some of you may be missing something here.

When you use FTP with mTCP to transfer files from a Windows machine to a DOS machine the FTP program will not be able to transfer those files that have file names that do not conform to the 8.3 format. It will produce error messages, e.g., 'Bad Path or Filename' and 'Critical File Transfer Error' in the log.

Examples:

File1234.zip will transfer but File12345.zip will not.

File1234.htm will transfer but File1234.html will not.

So, if you've got a group of files that contains both files that do and don't conform to the DOS 8.3 convention you're outta luck because you're gonna end up with a mixed bag on the receiving (DOS) end since none of the non 8.3 files will transfer successfully. In actuality you've created more work for yourself since now you've got to *sort* through the original files to remove the ones that don't have 8.3 filenames and transfer them in some other manner.

Why bother with the FTP at all if you've got to do triple the work in the end and will still need to use some other method to get the original job done? This is why I use the DOS-USB method where you copy all the files you want to transfer to a flash drive and then copy all of them to your DOS tweener and let DOS sort out (munge) the long filenames to something with a tilde that it can deal with, i.e., File12~1.zip when it encounters File12345.zip on the transfer list.

Stone
February 6th, 2016, 05:07 AM
Dealing with DOS 8.3 name restrictions: we used to use a little utility called RENAMEWIZ. Link here (http://download.cnet.com/RenameWiz/3000-2248_4-10257570.html)I don't see how that doesn't create more work for you:

1) You rename the renegade files to some 8.3 names.

2) You transfer them to your DOS tweener (via FTP).

3) You're left with a group of files with 8.3 names on your Windows machine where 8.3 names are long passe'. So you need to rename them back to their original names.

If you use the USB-DOS method they automatically get renamed(munged) as soon as they hit the DOS environment and the original files on the Windows machine don't need to be re-renamed back to what they originally were. :-)

mbbrutman
February 6th, 2016, 06:57 AM
Why use FTP? Because it eliminates the need for the 'tweener' system entirely!

You are complaining that FTP can't deal with the long filenames. (It's not an FTP problem, it's DOS.) You don't want to rename files before copying but really with that entire other computer and OS that is exactly what you are doing.

I use my 'tweeners' for things my older machines can't do - make boot diskettes or do media conversions when there is no networking available. If there is networking available the tweener is not needed. It sounds like you use it to get the automatic file renaming that vfat supports. I'm not sure if that is worth the effort when you probably want names that make more sense on the DOS side.

Stone
February 6th, 2016, 08:21 AM
You are complaining that FTP can't deal with the long filenames....

I use my 'tweeners' for things my older machines can't do - make boot diskettes or do media conversions when there is no networking available. If there is networking available the tweener is not needed.Not always... here's some recent examples of files I couldn't get transferred via FTP:

1) MemTest86 Because the filename is MemTest86+-V5.01.floppy.zip. :-)

2) Microsoft Space Simulator, because I had it stored in a ZIP named Microsoft-Space-Simulator.zip

You see, I also use my tweener for testing and running DOS software of all types so there's a bunch of utility programs on it as well as some games I haven't looked at in a while.

Different strokes for different folks and different needs. No one solution fits all and this is a primary example.

There are enough occasions that arise where I am just stymied by FTP's inability to do what I need to do with regard to DOS' 8.3 convention. So I've adopted the USB-DOS method which works for every file, every time. You know, if it saves a little wear & tear on my brain I'm all for it. :-)

Chuck(G)
February 6th, 2016, 09:21 AM
Copies a remote file to the local computer using the current file transfer type. See also mget, which can copy multiple files.

Syntax: get remote-file [local-file]

Parameter(s):
remote-file
Specifies the remote file to copy.

local-file
Specifies the name to use on the local computer. If not specified, the file is given the remote-file name.

I still don't see the problem. If you've fooled with Unix/Linux at all, the confusion in file names is present even without ftp; viz, "myfile.dat" is a different file than "MyFile.dat". Ftp basically has an implicit rename function, so you can call the local version whatever you want.

mbbrutman
February 6th, 2016, 09:49 AM
I try not to split hairs, but in this case we need to be precise. Just to recap:

FAT filesystems (FAT12, FAT16, FAT32) do not support long filenames. Long filenames are hacked on by using hidden directory entries. You need an OS or an extension that supports them natively to use them. Otherwise, you get standard 8.3 filenames.
DOS 6.x and below do not support LFNs without a third party driver.


Your USB stick has long filenames on it because you start with an OS that does the hidden entry trickery to add them to the base FAT filesystem. When you move the USB stick to an older system without LFN support, you see the original FAT directory entries which are in the 8.3 format. Your older system works happily with the 8.3 files. It knows nothing of the hidden entries, and does nothing to maintain them.

You are depending on DOS to ignore the hidden entries that store the LFN information. This becomes problematic if you delete and create a file with the same name. Renaming might be broken too. It's a very brittle system.

You are not 'unable' to transfer files using FTP. FTP is fine. The underlying problem is that the OS you are transferring to requires the 8.3 filename format with very specific characters and rules. When you use the USB device and move it between systems, the other OS is effectively doing the rename/long filename mapping for you, so you get to work with those joyous MICROS~1.BAT files. So really all we have is just a matter of where the renaming is being done. With your 'tweener' the OS on that machine is doing it. With FTP you have to do it yourself.

I think it's more correct to say that you are sharing a filesystem between the two machines using USB. Contrast this to copying the file from the USB device onto the local hard drive; you'll lose the long name information when you do that.

Sharing the filesystem is more convenient because you do preserve the long names. But woe unto you if you do something stupid, like run a directory name sorter. And I have no idea what Chkdsk does if it sees an LFN entry in the FAT. There is a lot of potential for unintended side-effects when you move the filesystem to a lesser OS.

As for FTP, it will move whatever you want just fine, and even let you rename it on the same command. It's not an FTP problem - it's a DOS problem.

Stone
February 6th, 2016, 10:52 AM
As for FTP, it will move whatever you want just fine, and even let you rename it on the same command.Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :-)

krebizfan
February 6th, 2016, 11:08 AM
Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :-)

Get a better FTP client. Attachmate's client included such automated rename features.

Chuck(G)
February 6th, 2016, 11:46 AM
Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :-)

I don't understand, exactly. One of the reasons for renaming to begin with is that the local system doesn't support the original (remote) file name. So you won't get the original named file on your local system anyway.

Stone
February 6th, 2016, 11:58 AM
I don't understand, exactly. One of the reasons for renaming to begin with is that the local system doesn't support the original (remote) file name. So you won't get the original named file on your local system anyway.Maybe I don't understand. When you use the FTP client to rename the file it does so on the Windows system before transferring the file to the DOS system. So you end up with the renamed file(s) on both systems, hence the need to unrename the file(s) on the Windows system.

mbbrutman
February 6th, 2016, 12:24 PM
There is an FTP rename command. But the renaming we are talking about is different.

Most FTP clients lets you specify a filename to fetch from the server, and an optional filename to use when writing it on your local system. The server side name is untouched; you just simply receive the file with a different name that is suitable for your local system.

For example, get <server_filename> [<local_filename>] is the syntax most clients use, where <local_filename> is optional.

Stone
February 6th, 2016, 12:27 PM
Apparently FileZilla doesn't support that. :-)

mbbrutman
February 6th, 2016, 12:33 PM
Sure. But the mTCP FTP client certainly does, and that's kind of where this thread of the conversation started from, right? Unless you are running FileZilla on a DOS system. ;-0

Most command line FTP clients support the remote-name and local-name syntax for both gets and puts.

Chuck(G)
February 6th, 2016, 04:16 PM
That's pretty much what I was saying--and why I included the quote from Microsoft ftp docs.

But there are scads of ftp clients.

mbbrutman
February 6th, 2016, 05:19 PM
Yes Chuck ... we are both aligned on the side of goodness. But Stone wasn't getting it. If I had a nickel for every time I thought 'I just said that ...'

I suspect Stone didn't know about that handy little difference between remote and local filenames. After looking at the way that LFNs are implemented I'm totally horrified. For read-only purposes it is safe but it seems really fragile otherwise. The mTCP HTTP server completely sidesteps the LFN problem on pure DOS; it lets you serve paths with long filenames by using its own mapping, kept in the equivalent of a .htaccess file. In retrospect I'm glad I did it this way, but obviously its not portable.

Chuck(G)
February 6th, 2016, 07:01 PM
Does mTCP use the long filename APIs if they're available on DOS?