• Please review our updated Terms and Rules here

Linux/BSD replacements for XPians

I've tried them all from 1987 machines to the latest and greatest AMD and from MSDOS 2.1 to Windows 7 and different Linux distros. From trial and error I've found a few things:

Linux seems to like running on the second-to-the-last generation hardware. Drivers for the newest software are hard to find.

Some distros play nicer than others. Newer hardware runs older software fine (to a point) but older hardware chokes on newer software. Newer software is easier to install software but older software is faster to install but harder to configure. Windows, for the most part, is the easiest to install as it seems to follow a known pattern. Drivers are bundled with hardware. Linux distros, while based on the same general platform, are very-much different from each other installing and running.

Linux system configurations seem to follow a different tack from each other and Windows, but can be configured to look and act nearly identical in operation.

Lastly, Linux, if configured properly and run on a stable platform, is much more stable, secure and maintenance-free than Windows although Linux may run slower or faster (I don't know why?). Linux may, or may not, use more or less memory as Windows. There's more available freeware on Linux but software appearance and function can be different from program to program. Software written for Windows typically follows the Microsoft "style" for appearance and function. Software installation is very different between Windows and Linux and Linux software installation can be daunting.
 
deathshadow said:
Though [netbooks created] more of a "prolonged XP life span" thing than a Win 7 x64 thing
Click to expand...

What the netbook did was show just how bad of a pig Vista was; otherwise 7 might have been Vista++.

As to 2k8... comparing that to win7 is splitting hairs.
Click to expand...

Perhaps.

Probably the best all-around desktop OS, particularly Windows 7;
Click to expand...

Well, I have a pile of scanners, printers, and assorted other hardware that have no Win7 driver; I have a few that, even though the driver should work OK it can't be installed, because the 16 bit thunking WoW layer in the NTVDM is no longer there in x64; the installer for the 32-bit drivers is a Win16 program. I have a pile of programs that work better in the commercial version of WINE, Crossover Pro, than they do on Win7.

I much prefer the relative simplicity of Linux driver support in the main (one major exception is the driver package for Samsung multifunction devices; yeah, they make drivers for Linux but they're a bit baroque). Printers are just about the easiest thing, thanks to Apple's development of CUPS, used by basically all Linux distributions. It really is for the most part as simple as grabbing the right PPD out of the Windows driver and dropping it in the right place in CUPS, for those few printers that don't have excellent support already.

The simplicity is usually that, if it's not easy, it's just about impossible, and is as close to a pass/fail as you can get. On Windows there are lots more 'partially' working drivers, in my experience.

I have this mantra -- Windows is for desktops, *nix is for servers -- and never shall the 'twain meet. Varying from this is using a deuce and a half lump to drive that square peg into the round hole. You might make it fit, doesn't make it good.
Click to expand...

Since I have driven a deuce and a half as a temporary commuting vehicle, this analogy did draw a chuckle..... But I'm rather happy using CentOS 6 as my primary desktop. We'll see how CentOS 7 plays out, since there are quite a few changes. At least C6 will be supported to 2020.
 
BTW I run DOS 3.3, Win 98SE, Win 2000 SP4, XP SP3, Vista SP2, 7 SP1 and Kubuntu Linux on various systems and I run an XP SP3 VM under Linux. I've run Suse and still plan on installing dual-boot. I once had the latest 32 bit version of Mandriva. And yes, I still use the command line for all of them. You can't get around it to work "under the hood".
 
Chuck(G) said:
Well, here's a big issue--Win7 64 isn't going to run DOS programs, is it?
Click to expand...
DOSBox... after all, where do you think Paku Paku was compiled and tested? (with code edits done using a modern scintilla based editor -- Flo's Notepad 2, which thankfully isn't a complete piece of Scite like some other editors I just named...)

But then, I've been on x64 versions of Windows on my workstations for a DECADE now so... I'm used to the idea.

Windows XP x64 Corporate -- BEST OS they never pushed hard with; even if it is just Server 2k3 in drag. Of course, I may have just liked it as it didn't have WGA. Make of that what you will...

The loss of Win16 for some reason didn't bother me... for some reason things seemed better without it; but I was an early adopter of x64 so...
 
lowen said:
Since I have driven a deuce and a half as a temporary commuting vehicle
Click to expand...
I have the feeling you are thinking of the truck -- as It's unlikely you drove a baby sledgehammer to work. Never heard of a lump hammer? Admittedly, 2.5 pound ones have given way to 3 pound models, but still...
http://www.aspli.com/products/636/carters-2.5lb-lump-hammer

It's actually the joke -- the 2.5 ton truck was called a "jump" since it was brute force like a lump hammer.
 
deathshadow said:
DOSBox... after all, where do you think Paku Paku was compiled and tested? (with code edits done using a modern scintilla based editor -- Flo's Notepad 2, which thankfully isn't a complete piece of Scite like some other editors I just named...)
Click to expand...

A lot of my scripts are a mix of DOS and Win32 CLI programs. The last time I checked, DOSBox didn't do Win32.

Wine in Linux tries to integrate DOSBox with Win32, but it doesn't succeed. You really want to pass environment variables, run batch scripts with mixed program, etc. If DOSBox were more like some the CP/M emulators that allow you to run 8 bit program in the 16-bit DOS environment transparently, that would be nice. DOSEmu can do that, but doesn't succeed in running Win32 programs (I've tried HX-DOS and it doesn't like DOSemu).

Actually for a lot of what I do, Win98SE is perfect. I get real-mode access to I/O ports; I can run any mix of 16- and 32-bit programs and nothing complains. But sometimes I need XP's capabilities too.

I can get by on XP by using special drivers that change the IOPL on ports for programs that need them--but that apparently doesn't work on 64 bit and not on 32- or 64-bit Win7. Both 2K and XP were perfect. After that, everything goes to hell.
 
Last edited:
Chuck(G) said:
A lot of my scripts are a mix of DOS and Win32 CLI programs.
Click to expand...
Why the devil would you do that in the first place?!? That's just BEGGING for things to fail... I'm sorry, to me that's a "doctor, doctor, it hurts when I do this" moment.

Though yeah, I've seen a lot of little in-house crapplets pull those types of stunts, and it's development techniques like that which resulted in things like, well for example companies who can't update to the new OS or browser because their in-house crapplets won't work... which honestly to me just means sloppy development practices.

People often seem to want to treat batch scripts as if they're a real programming language or use them to 'glue together' programs that were never meant to be glued together -- it's one of those things that I've seen bite developers in the backside time and time and time and time and time again the past twenty years.

Which is a laugh when 15 year old batch scripts don't work on the latest OS, but a 1999 game engine -- something a thousand times more complex -- runs JUST FINE. (and in the case of the Dark Engine, gets more effort in keeping it up to date).

Chuck(G) said:
I can get by on XP by using special drivers that change the IOPL on ports for programs that need them--but that apparently doesn't work on 64 bit and not on 32- or 64-bit Win7. Both 2K and XP were perfect. After that, everything goes to hell.
Click to expand...
Really, true 32 bit and 64 bit OS are designed to not give you that low level an access to ... well... anything unless you're actually writing a driver... It's actually the Posix model of doing things; hence why doing certain things in Linux, FreeBSD, Solaris, etc, etc... are a royal PITA.

It's actually the removal of the ability to get at those that's supposed to make modern OS more stable -- though as both Windows and Linux users can attest, in implementation that's only as good as the people who wrote your drivers... and if you lack the skill to write a driver, the time to learn to write a driver, and need that level access, you're pretty much SOL.
 
Show me a CLI version of Vern Buerg's LIST utility. Not a Windows GUI version, but a genuine text-mode one.

There are plenty of times when I'd like to write a 16-bit version of something, but memory needs trump the implementation.

As far as writing Windows mode kernel drivers--been there, done that--from the time of Win 3.0 to XP. I can gobbeldy-gook IoSkipCurrentIrpStackLocation () and IoAttachDeviceToDeviceStack(), KeInitializeSpinlock() and all that other stuff with the best of them. Write four times as much code as you really need. Deal with BSODs debugging it. Wonderful fun. And you have to keep changing them for every new platform, it seems. Linux is really no better.

A lot of my stuff is one-of-a-kind-designed-by-me that will never see prime time.

So tell me about how not to mix 16 and 32-bit code... One-off 16-bit real-mode code is wonderful in its simplicity.
 
Chuck(G) said:
There are plenty of times when I'd like to write a 16-bit version of something, but memory needs trump the implementation.
Click to expand...

While I know this is a bit off-topic, the book 'Unauthorized Windows 95' shows how to bring up a 'Protected Mode DOS' on a Win95 system, in Chapters 6, 7, and 8 (that is, rather than loading the GUI, loading command.com with full DPMI-accessible memory in 32 bit mode). That book should be on every vintage Win95/98-era PC enthusiast's reading list, even though it is quite technical. Most interesting is how this technology showed up in a beta version of MS C version 7, but the overhead of pulling in 500K of things cause MS to release MSC7 with Qualitas' 386MAX. In the beta MSC7, the Win386 kernel shows up by another name as the MS-DOS Protected Mode Interface, or MSDPMI.

For Win95, 98, and ME, the kernel changed names, but is essentially the same beast as Win386 on WfW 3.11. The new name is VMM32.VXD, and it is possible to load into a CLI-only 32-bit 'DOS' by fooling VMM32.VXD into loading COMMAND.COM rather than KRNL386.EXE. You even get 32-bit file access and long filename support in INT 21H calls.

The technology of running mixed 16 and 32 bit code, particularly the case of a 16 bit program calling a 32 bit routine, is actually covered by US Patent 4,974,159. So you can look at the technique in detail.
 
lowen said:
The technology of running mixed 16 and 32 bit code, particularly the case of a 16 bit program calling a 32 bit routine, is actually covered by US Patent 4,974,159. So you can look at the technique in detail.
Click to expand...

...commonly referred to as "thunking". Been there, done that--very common in Win 3.1 and 95.

But back on track, DOSBox won't run 32-bit code--not even if you supply a DPMI server of your own. So DOSBox may be fine for the vintage game players, but it's not a real solution.
 
Last edited:
lowen said:
While I know this is a bit off-topic, the book 'Unauthorized Windows 95' shows how to bring up a 'Protected Mode DOS' on a Win95 system, in Chapters 6, 7, and 8 (that is, rather than loading the GUI, loading command.com with full DPMI-accessible memory in 32 bit mode).
Click to expand...

You could do this with Windows 3.1x too using a file called WINSTART.BAT, except its DOS box wasn't as compatible with programs. In terms of memory access its no different than running EMM386 or QEMM on boot.

lowen said:
Well, I have a pile of scanners, printers, and assorted other hardware that have no Win7 driver; I have a few that, even though the driver should work OK it can't be installed, because the 16 bit thunking WoW layer in the NTVDM is no longer there in x64; the installer for the 32-bit drivers is a Win16 program. I have a pile of programs that work better in the commercial version of WINE, Crossover Pro, than they do on Win7.
Click to expand...

How old is the scanner and printer? I haven't seen Win16 stub installers in quite a long time. I haven't had driver problems with older devices either. One printer here is an old 2001 HP Officejet, both the printer (LIDIL based) and scanner work fine on 7 x64. My 20 year old Laserjets all work fine since they speak PCL and Postscript.
 
Chuck(G) said:
Show me a CLI version of Vern Buerg's LIST utility. Not a Windows GUI version, but a genuine text-mode one.
Click to expand...

I'm guessing you are referring to this program: http://www.bizer.com/zblist/

Honestly, he should port it to something text based. It'll likely be more compatible than a VB6 application (written in 2009!) with later versions of Windows. This is why open source is good, someone likely would have ported to to be a true Win32 console program by now. ;)
 
Yeah, I've seen zblist. It seems to have escaped him that most users of LIST run it from a command line.

Linux/Unix has hd/hexdump, but it's not nearly as nice to use.

But another example--I have an invoicing program written in QB that shells out of a database program and then outputs printed material in HP PCL, which then feeds into GhostPCL to create a PDF file. Why on earth should I rewrite all of that because some idiots have decided not support older platforms? Has Intel decided to abandon the 16-bit x86 instruction set or V86 mode?

Hell, I still know of a guy who uses Micropro Datastar in CP/M emulation mode on his XP system. Yup, that's right--Datastar, the cousin of Wordstar.
 
Chuck(G) said:
Yeah, I've seen zblist. It seems to have escaped him that most users of LIST run it from a command line.

Linux/Unix has hd/hexdump, but it's not nearly as nice to use.

But another example--I have an invoicing program written in QB that shells out of a database program and then outputs printed material in HP PCL, which then feeds into GhostPCL to create a PDF file. Why on earth should I rewrite all of that because some idiots have decided not support older platforms? Has Intel decided to abandon the 16-bit x86 instruction set or V86 mode?

Hell, I still know of a guy who uses Micropro Datastar in CP/M emulation mode on his XP system. Yup, that's right--Datastar, the cousin of Wordstar.
Click to expand...

Point your blame at AMD. They were the ones who developed x64 Long Mode and removed the "legacy cruft". The database program sounds Rube Goldberg-ish, but that can at least be modified to work with DOSBox.
 
BTW, disabling hardware acceleration in Firefox didn't cure the problem. I hit "Reqly" here and the response box still misses displaying lines or has other garbage from the screen in it.
 
njroadfan said:
You could do this with Windows 3.1x too using a file called WINSTART.BAT, except its DOS box wasn't as compatible with programs. In terms of memory access its no different than running EMM386 or QEMM on boot.
Click to expand...

Yes; Win95 wasn't the huge leap most thought it was. At least not relative to Windows for Workgroups 3.11.

How old is the scanner and printer? I haven't seen Win16 stub installers in quite a long time.
Click to expand...

Mid 2000's for the most part, although one high-end Agfa SCSI scanner was just barely supported on XP. And there are some old astronomical freeware packages that are still useful, some even unsupported but working, that have Win16 installers.

I haven't had driver problems with older devices either. One printer here is an old 2001 HP Officejet, both the printer (LIDIL based) and scanner work fine on 7 x64. My 20 year old Laserjets all work fine since they speak PCL and Postscript.
Click to expand...

Those work fine, yes.

But I have several still-usable devices that just simply don't have the support. Some aren't printers or scanners, but are a bit more arcane. I have a Tascam US-428 and a Tascam US-224; driver support from Tascam for any 64 bit system doesn't exist. Or, in a Tascam Rep's words: "We do not have Windows 7 compatible drivers at the moment. We are working on Windows 7 drivers for all of our current audio interfaces, they will be available for download on our website very soon. This product is discontinued so there might not be a Windows 7 driver being developed."

Both the US-428 and the US-224 are still in fantastic condition, and the audio quality is wonderful (not to mention the fact that they were not cheap, and other than lack of drivers there is absolutely no reason to toss them). I just have to either use them with AVLinux (which supports them as of 5.0.3 perfectly with a bit of tweaking) or Mac OS X 10.6 and earlier. Completely unsupported on 10.7, 10.8, or 10.9. So I keep my 10.4-running PowerMac G4 FW800 with dual 1.42GHz CPUs around for recording purposes. And, no, I have no need (nor the money!) to replace them any time soon. When the PowerMac goes bye-bye (and it will soon enough, their power supplies are a bit notorious) I'll be doing all of my recordings either with my Edirol R-09 handheld or with the Tascams on AVLinux.

I can't just replace them with a straight sound card, either, since I actually use the control surface built into them for DAW control; it was the presence of a usable control surface, especially the jog wheel, that caused me to buy them in the first place.
 
You must log in or register to reply here.
Back
Top