My solution to Win95/98/ME security is to not let it within a million miles of the internet. I have other boxes (XP+Linux) which are allowed 'net access.
The only remaining '98 box is primarily a Linux box, with 98 dual-boot for older software which is never going to run on NT/2K/XP/Vista (games, mostly). The Win98 installation doesn't have any kind of network connectivity. The only way anything gets onto that disk is: download under Linux (or on the XP box), move to Win98 disk, boot into net-less Win98.
Some of those buyers will be industrial. There's a heap of legacy packages around associated with PLCs and other programmable control devices which were written in the DOS days, and have things like BIOS and DOS calls embedded in the code, as well as other Win32 no-nos such as wait loops. Some of them work better than the modern Windows equivalents... if those exist. After W98 the rot set in for that sort of software.
USB and PCI are not always better - certainly not "far better". They certainly have their uses, but nothing (on the PC) comes close to the parallel port for simple, cheap and reliable interfacing. I have large numbers of programming and debugging interfaces for different microcontrollers, using both parallel ports and USB interfaces. I have no doubt which is the easiest to deal with, and has least issues with drivers, and which is easiest to use with different software. USB interfaces are often faster, and can be better in some ways, but the parallel port still has many advantages.
RS-232 is far more "plug and play" than USB ever has been. You plug your device into the comms port, and you run the appropriate software on the computer - everything works. There is no question about installing drivers (do you have the right drivers for that particular computer? Do you have the appropriate user privileges?). USB is not bad, of course, but RS-232 is often very much easier.
For the average computer user, USB is normally a better choice. But for electronics developers and embedded systems programmers, parallel ports and comms ports have a lot of advantages.
It can be a configuration management issue. If I have to tweak a design done eight years ago for an aerospace customer, then I have to be able to run the software at the same version levels as they were at that time, and that means running Win98.
We have operating systems in our archive going all the way back to CP/M, if needed. The hard part is keeping the hardware going that will run the old stuff.
================================
Greg Neff VP Engineering
*Microsym* Computers Inc. snipped-for-privacy@guesswhichwordgoeshere.com
Unfortunately the laptop didn't have a DVD drive, or even a CD drive, for that matter. It was a Pentium 60, I believe.
We did try downloading a Knoppix CD from the cafe (I left mine at home, not thinking it was necessary), but the download would have taken 8 hours at the cafe (DSL speeds). The country was the Philippines.
I keep old machines around for that. I have some machines here going back to 386s. (My Kaypro 286i board has since corroded.) And I like ISA because even a hobbyist like me can design a working board for it and have it run the first time and I don't need expensive equipment to deal with a reflection wave bus, serpentine clock lines to get the
2.5" +/-.1 length and clock skews. The new equipment has left us hobby types behind.
No... most of them work just fine with USB-to-parallel converters.
Are there really that many new printers that only have parallel ports (and not USB)? I'd be surprised if it's more than, say, 5% of all models available anymore?
Same thing, USB-to-serial converters generally work fine with modems.
That post of mine was a little muddled -- I was trying to address more the problems with using parallel ports and (to a much lesser extent) serial ports as "generial purpose I/O ports" using protocols that are something other than "standard Centronics" and "standard RS-232." The parallel port has been much abused, certainly, but hooking up a printer to it is of course anything but abuse. :-)
Well, perhaps they're not available from Microsquish anymore, but there certainly were plenty of security patches issued over the "supported lifetime" of Win98.
When I don't have enough time to personally become a Windows security expert and therefore realistically be able to judge for myself which patch true security holes and which are little more than an anti-piracy campaign by Microsquish, as "Windows Genuine Advantage" is?
Sure, but it probably wouldn't have animated folders dancing around when you asked it to delete a directory. :-)
Sorry, "reliable" and "parallel port" for general purpose I/O just don't go together.
I've had far more problem over time with parallel port dongles like that than USB ones. Especially if you already have, e.g., a software protection dongle for the microcontroller's C compiler hanging off the parallel port!
Not quite. You have to tell the "appropriate software" what COM: port to use first... or hope that it's able to figure this out automatically. USB provides a standard way to do this -- you don't have to keep "rolling your own" code to do so. Similarly, if you have a standard USB device (e.g., HID class, mass storage class, etc.), you can plug it into a Windows PC, a Linux Box, or a Mac and it all "just works" -- no one has to port the application from OS to OS.
From some random piece of scientific equipment I can see this as being the case. For memory sticks, keyboards/mice, etc., USB is certainly the way to go.
The fact that USB gives you power is another nice little benefit.
I really think this is more a perspective/experience issue than an objective truth (i.e., if you'd been using USB for years now and I asked you to switch to serial/parallel ports, you'd be telling all the advantages of USB :-) ), but of course I'm just as subjective as anyone else so I'll just drop it.
Still, have you LOOKED at the USB 2 manual? I have it here, nicely printed out, plus the HID stuff. Whew!
I'm doing some USB now. But I definitely think ISA was a lot easier and NO software involved except for the PC side, which was much easier and works under DOS just fine where I have COMPLETE control over things.
Not USB 2, but I did do a full-speed USB device mostly from scratch (writing all the microcontroller routines to receive, send and parse data packets -- but I did have the manufacturer's example code to start with). It was time-consuming and convinced me that, unless you really high-performance, chips like those from FTDI are the way to go -- at least for anything that's relatively low-volume.
This is something of an illusion: You never had control of how those ISA signals were generated on the PC side (and as I recall, there were some discrepancies from vendor to vendor in the exact timing of ISA on occasion... although I'd agree that if you just doing a card using port I/O -- no memory read/writes or fancy DMA -- it really was dead simple to make it work). With USB (and PCI, to a lesser extent), you can just plop down someone else's chunk of silicon and still have the same thing. Sure, you're trusting that silicon to "do the right thing," but is that really that much worse than trusting the CPU or north or south bridge ICs in the PC itself to do so?
There is just soooooo much more to worry about with USB. And a lot of it is software. Let's say I want to develop my own 16 dig I/O and 4 channel analog DAC and 2 channel analog ADC board for some custom job. In USB, I need to worry about which method I'm going to use with USB (will it be HID or CDC class or whatnot) which means I have to first KNOW something about it, which means reading A THICK BOOK!! Then, I have to find out what comes standard with Windows. And there is NO WAY it is going to work under a DOS system, where USB support is thin at best. And that's before I get around to having to work out the microcontroller and extra ICs I'll need and then the software on the micro-side, if it includes a USB pinset, or yet another manual on the FTDI chip, I suppose, if I use one. And then....
Well, ISA was dead trivial, by comparison. Solari's book was all I needed. Everything else is trivial.
Never noticed a problem on the PCs I used. 8-bit transfers were 6 cycles (old XT style), 16-bit transfers could be 3-cycles if you wanted (AT.) Plenty of time for things, easy to do, no-brainer. There were NO variations in the older boards, with the really old ones clocking the bus directly with the CPU. With the advent of faster cpus, they decoupled the cpu from the bus, but the cycle times were reliable on it and the faster cpu easily could fill the bus capability.
The new systems with the south bridge involved did have their problems. For example, ISA DMA cannot be properly driven over as PCI transactions, so the south bridge needs sideband signals to the main chipset to tell it what in the hell is going on and to avoid interrupting smoe transfer. These sideband signals were/are a source of most of the chipset bugs.
Doing the work in DOS and using assembly I could watch a quadrature encoder with 10k counts/sec running at 250RPM, including the +/- variations on the encoder with means my minimum timing was quite a bit less than the 24us that might suggest, and do it quite reliably with a minimum of 5 reads per level before a transition.
And there was NO mystery.
Over USB, I'd not only have all the information overload problems in such a quadrature encoder design but then I'd also have to add a micro, one of those FTDI chips, do the decoding on the remote micro, and work out a whole set of protocols of my own. And probably a whole lot of other stuff, to boot.
I guess you could say that I'm not all that happy with suggestions to "go use USB." It's not a panacea, for one thing. And it is a LOT MORE work to master, for another. And it forces a shift of certain reponsibilities, in many cases where I'd rather have options than being forced.
In my experience (with debuggers rather than general purpose I/O), "reliable" goes together with "parallel port" much better than "USB". YMMV.
I've always managed to avoid parallel port dongles - there is no doubt that they are a pain in the neck, especially when you want to use the parallel port for something else. If you've had to use one of these along with your parallel port debugger(s), then it's no surprise you've had problems.
If the device you are using (or making) fits a standard class, then it's much easier. But if not, things can be more complicated.
Again, for standard USB classes life is easier. But I have far more random pieces of development equipment (or boards we have made ourselves) - I guess that biases my opinions.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.