Ask Slashdot: Supporting "Antique" Software? 212
First time accepted submitter wolfguru writes "As the IT Manager for a large printing firm, I often have to provide hardware to support older software which is used to configure and maintain existing systems, some of which are nearly 20 years old. Much of the software uses RS-232 serial communications to connect to the PLC devices and is often 16 bit versions. Newer systems from the PLC manufacturers supports some of the equipment, but many of the older PLC consoles are essentially unreachable without the serial communications. For any of you faced with similar challenges in keeping a manufacturing environment maintenance department working; what do you use to support them and where do you find equipment that will run the older systems that are sometimes the only means of supporting these types of devices?"
Virtual Machines (Score:5, Informative)
Fortunately RS232 is still well supported via PCI-e cards and USB, so you can just run the old system in a virtual machine on modern hardware to avoid many of the problems associated with maintaining old gear.
My only other advice is to never underestimate the costs, especially when talking to your boss. He/she will want guarantees that everything runs smoothly all the time, which realistically you can't provide without plenty of redundancy and extensive testing. Be clear that old hardware is hard to maintain and repair, and not trivial to replace.
Re:Virtual Machines (Score:5, Interesting)
Re: (Score:2)
Already posted this, I have had DOS apps that just don't work on new machines and with a bit of patching DOSBox worked fine..
Also mentioned in the same post, I have recently found a few cases where 5 different onboard serial ports failed to work but a USB port worked just fine... really strange.
But dos and older windows 9X apps / os may not (Score:3)
But dos and older windows 9X apps / os may not like USB to RS232 and or pci / pci-e based RS232 ports. Also VM pass though may not work 100%.
You can try running free dos / MS-DOS 7.x or 8 on newer hardware but usb may not work as well.
Comment removed (Score:5, Interesting)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
I've done this. The easy answer to your problem is: virtualization.
Whether you're virtualizing DOS or Win9x, you can use modern USB devices as "real" serial devices on the guests. It works slightly differently with the different platforms (VirtualBox and VMWare are the best at this with VB being the best, in my experience, with XenServer failing and being difficult more often than not). With VirtualBox at least, you can pass a raw port to the guests.
You MAY run into problems with port timing, however. Findi
Re: (Score:2)
Please, noone who has business needs use Virtualbox.
There are a lot of free / basically free virtualization products out there suitable for business. Unless VBox has substantially improved in the last year or two, it isnt one of them.... unless you like random hangups / VM corruption.
RS 232 to ethernet adapters (Score:4, Informative)
They are a god send. For software I use RSlinx Gateway which is for Allen-Bradley PLC's, but has many different driver solutions. Also it will allow you to bridge network connections if your running DH 485/RS 232/DF1/ DH/DH+/Ethernet. Gateway is expensive though there might be a more cost effective solution.
Re: (Score:3)
Don't know about the particular device you mention but just want to remind everyone to "put some thought into things" before just slapping ip->ethernet->rs232 gateways around all over the place. Many of those old RS232 interface had no authentication or access control, the ones that did usually it was a weak password or pin and no rotation or change period enforced. Lots of the remote ip -> serial port solutions I have seen run clear text too, so even if there is a password on the controller it
Re: (Score:3)
Anyone who merges their production industrial network with their common business network deserves everything they get.
There should be an air gap between industrial control networks and business networks, and the industrial networks should never be able to touch the internet.
Re: (Score:3)
Re: (Score:2)
aka Terminal Server (Score:3)
When you buy a rack mounted unit that does this, it's sometimes called a terminal server. You can provide network to serial access, enable unique passwords on each device and create access lists. When I managed customer equipment, I used to require a DECserver and modem/phone line for last ditch access. In this case, I had firewall, switch, router and console access. Much of this kit is can be found used or see Vnetek [vnetek.com]. I understand Cisco also makes comparable product. You can pair this with virtual co
Re:RS 232 to ethernet adapters - Security warning (Score:3)
RS232 to Ethernet devices have a big security problem - they can expose your RS-232 device directly to the Internet. Many RS232 to Ethernet devices will talk to anything that tries to talk to them. Some have built-in minimal web servers for configuration, and those make it easy for attackers to find the device.
Industrial automation people try to have isolated Ethernets for these devices. But then something comes along that needs to be on the isolated net and also needs to talk to something in the outside
Re: (Score:2)
100% of RS232/RS485 to ethernet adaptors I have worked with have had at minimum IP level filtering. Trivial to defeat, I know, but most sit on networks with no direct connection to the internet. And honestly if you've got a hack on your subnet you have bigger problems than the fact that he can access your unknown (to him) PLC. Like the fact that he can own your SCADA and break things without having to understand ladder logic in the PLC.... Worry about your SCADA first, and your conversion devices second....
Re: (Score:2)
Trivial to defeat,
Only if its UDP, and only if you dont care about return traffic.
Spoofing an IP is really only useful when you are flooding a target and really dont care about bi-directional communication, or if youre punching a hole in a firewall with the help of an intermediary server.
Re: (Score:2)
An RS232-to-Ethernet device is should be essentially a hardened Raspberry Pi running a modern Linux, configured for security. The communications should be established using ssh configured for login only using known keys. This can be set up relatively easily to be pretty foolproof and can probably beat 99.99% of commercial products out there when it comes to security. It's really not that hard.
Re: (Score:3)
Excellent call. You beat me to it.
The bridge hardware is worth every penny. By the time somebody grinds out a kludgey emulator zombie for some junk freeware, you're up and running with your system. In a factory environment, you often just don't have time to indulge in experimental development of custom applications.
You can also see if the old RS-232/485 gear is recognizable by a Phoenix Contact or Wago DeviceNet-Serial hub. That's even easier since all modern PLC's support DeviceNet out of the box, and the
Re: (Score:3)
The serial interface is not the problem, the 16 bit software talking through it is.
Re: (Score:2)
Getting 16-bit software running on a modern computer is easy: This is why God has given us VMs.
Getting a hardware serial port to work properly from within a VM is not always easy. This is why God has given us serial-to-Ethernet adapters which never get bogged down in the hardware abstraction of a VM.
I've got a few Lantronix boxes that seem to work well. DIN-mount, very flexible power requirements, a pair of RS-232/422/485 ports, and a pair of Ethernet ports with a dumb 10/100 switch in between them: The
Re: (Score:3)
Re: (Score:2)
and an isolated network for them I hope. not much security on devices expecting serial port communication.
It depends on the situation. If your serial port is simply monitoring some sensors then security isn't such a big deal. If your serial port is running a uranium purification centrifuge then I guess you may want to think a little about security :)
Also if your serial port is sitting in a workshop (locked cabinet or not) then internet security probably matters very little.
Have a look at PCs for Industrial Automation. (Score:5, Informative)
At work we use Industrial PCs for work with PLCs. You can still buy PC with an ISA slot, and most of industrial PCs have good old serial port. Just contact any competent supplied of industrial automation equipment.
One of manufacturers is Advantech. Have a look at their UNO line of "brick" computers. Plenty of industrial RS232 and RS485 ports even in the most basic models. Computers are fanless and built to last. Unfortunatelly, those machines are bloody expensive.
If you look really hard, you can even find new 486 machines. Those are even more expensive than Advantech bricks I wrote about, but there are still people that need those computers, so there are companies able to provide them at a cost.
Re: (Score:3)
You don't need an ISA slot to get serial ports. Just a few months ago, I put together a brand new computer at work that has two RS232 ports on a PCI-express card. You can get one from Newegg for around $50.
Re: (Score:2)
Fanless industrial PCs tend to be more than R500. Also they tend to run old hardware and DDR2 RAM is now really expensive. It is silly, but it is the way things are. And fanless is a must in, for example, an environment which corrodes copper or tin in solder. And yes, I do work in such situations.
Re: (Score:3)
You don't need an ISA slot to get serial ports..
No, but there are specialized boards that still have ISA slots. Sometimes it's considerably cheaper to replace the computer and keep the board, rather than vice versa. A new board will probably require new software, perhaps only available from a single vendor, and it may require retraining doctors, I mean users, who hate change. And, to be honest, if the old system did what they wanted, there's no reason to inflict something different upon them.
Re: (Score:2)
And there are specialized boards that still have ISA slots for specialized gear.
Without digging deeply at all, I found this: http://www.adek.com/ATX-motherboards.html [adek.com]. One of them has six serial ports, one ISA slot, a smattering of PCI and PCI Express, DDR3 RAM, and a socket 1155.
Re: (Score:2)
And there are specialized boards that still have ISA slots for specialized gear.
Without digging deeply at all, I found this: http://www.adek.com/ATX-motherboards.html [adek.com]. One of them has six serial ports, one ISA slot, a smattering of PCI and PCI Express, DDR3 RAM, and a socket 1155.
No doubt. And they've got a few with more than one ISA slot (I had 2 full-length ISA cards to insert). The software ran under MS-DOS, and the computer would never be used for anything other than the dedicated purpose, so PCI, DDR3, etc. was totally irrelevant.
So... we're going to take a random motherboard and find out how compatible it is with software provided by the manufacturer of those ISA boards in 1985? Does the software make use of direct access to the hardware of the computer that the vendor orig
Re: (Score:2)
Scientific equipment also is something where (due to low part numbers and long life-times) antique hardware is the standard.and totally obsolete drivers (say the newest version of windows these run on is windows me) are not impossible to find (to say the least). In 2011 i used perfectly fine equipment (HP, Tektronix) which was designed before the 90s.
x86 system on a chip? (Score:3)
You need to come up with a migration strategy (Score:2)
The strategy should include a short time support strategy for old hardware. You can run 20 year old software on today's PCs either directly or in a virtual machine. However, you might have problems, because they are too fast. This short term support must be supplemented by a migration strategy for the old PLCs. I know that is hard, have worked in a project using PLCs in railway control systems, which have to run for 20 or more years before they are replaced again. Therefore, you need also a strategy how to
Re: (Score:2)
I work with this software, and too fast is not a problem, as its the PLC that runs the software, you just need to run the funky 20 year old uploader on something
Re: (Score:2)
For the PLC part this is true, if replacement PLCs do not have a different sampling speed. However, I was more referring to the control software running on PCs. 20 year old software do sometimes timing stuff based on CPU cycles and even if not, certain problems first occur when the software is executed faster. But, yes, this is only an issue for PLC scenarios, where PLCs and PCs are tightly coupled.
Re: (Score:2)
That is what I love about Omron. Upload the program from, say a C2H, and download it on a modern CJ CPU, and everything seamlessly and flawlessly just works. Plant downtime rangers from zero to 15 minutes.... Other PLC manufacturers are very decent too, but bloody Siemens breaks between PLCs of different sizes on the same generation. Bastards. And Toshiba is still on Generation 1.
Re: (Score:2)
Siemens has sucked out loud in every imaginable way ever since they abandoned the old TI 505/Step 5 framework. Step 7 is grossly bloated for the scale it's good at, and fails miserably as a wannabe DCS.
Re: (Score:2)
Theres too much speed viratity to be clock synced with a CPU 20 years ago, it was an obsolete practice 15 years before that
I have exactly this problem.. (Score:2)
Re: (Score:2)
You need to reverse engineer whatever runs on those PLCs and implement using something contemporary and off-the-shelf. Pronto.
Re: (Score:2)
It could probably be done very nicely using today's components. You'd pretty much need distributed I/O, and one modern PC-based PLC would take care of keeping things running. Compared to legacy hardware, a codesys environment running on a modern i7 or Xeon box can really do what dozens of legacy PLCs had to do before. It's much easier to develop since everything is on one system, and you have modern IP-based communications available to tweak things.
16 Bit what? (Score:2)
You're not alone (Score:5, Informative)
Hi Timothy,
Unfortunately, you didn't provide a lot of information in your post as to what the problems are.
As people have pointed out, there are a ton of USB to Serial solutions out there so having the modern hardware with the ability to communicate over RS-232 is generally not a problem (although, depending on the connections used, you might want to invest in a RS-232 breakout box and read up on RS-232 handshaking as many of the older devices do use hardware handshaking). I have a few hand wired 9 pin to 25 pin connectors with the CTS-RTS and DSR-DTR pins shorted together as they can simplify your life immeasurably.
In my experience, the biggest problem is retaining floppies & CDs with the original software on them (assuming that the developers are no longer supporting the product/are out of business). If the company is still in business, usually they're pretty good at providing updated software for their products. If they're not in business, then look to see if they were bought out by anybody. Chances are you'll find that the purchaser is still supporting the product, although it may be under another name.
Personally, the biggest issue that I see when I have encountered this type of situation is that the original programs are on floppies. If this is the case, you will need to find somebody with a Windows/95 machine that they're keeping together with spit, bailing wire, gaffer's tape and good intentions - you should be able to copy the program onto a USB key and then burn it on a CD/DVD for more permanent storage.
Once you have the program in a media that you can work with, you may have problems with the installation. You will probably have to create a virtual machine on your PC AND there may be 16 bit programs that you have to convert to 32 bit - here's a great resource that's saved me a couple of times: http://www.reactos.org/forum/viewtopic.php?f=22&t=10988 [reactos.org]
Finally, Google is your friend. Chances are the answers are out there for your particular equipment.
Good luck!
myke
Re: (Score:2)
'dd' (or rawdiskwrite, or whatever the Windows equivalent is) is your friend, as is virtualization. There is very, very slim rationale behind keeping these systems physical. Even SCO virtualizes OK in most scenarios.
Re: (Score:2)
For one application where a customer had to run an old 16 bit DOS application on a newer Windows box, I installed DOSBox (which is typically used for gaming) and it worked great. Mind you, it was a very simple piece of software and did not use rs232 communication, but instead was like a hard coded spreadsheet. A very specific, difficult to replace, probably no replacement existed, hardcoded spreadsheet. It worked great.
Re: (Score:3)
USB to serial adapters are shit. +/-6V instead of +/-12V and variable latency (USB does not guarantee latency). RS232/RS485 to Ethernet adapters are far better, but nothing competes with a physical port for some obscure finicky equipment. And yes, it is still out there working fine unlike the modern rubbish that fails if the air gets slightly moist.
Re: (Score:2)
USB guarantees latency if you have control of the entire stack :)
WTF! Shorting flow control pins! (Score:2)
I have a few hand wired 9 pin to 25 pin connectors with the CTS-RTS and DSR-DTR pins shorted together as they can simplify your life immeasurably.
Better be careful about shorting hardware flow control pins. I've seen CNC mills where someone did that. (Google "CNC Drip Feed"). The feeding PC didn't know the CNC controller buffer was full and kept sending data. When the CNC controller began accepting data again, it had missed hundreds of lines of code. The move commands drove the cutting tool into a bad place and people almost got hurt.
Your advice to learn RS-232 was excellent. But one must understand the flow control issues before you can know how
Re: (Score:2)
You can still buy USB floppy drives. They were very popular when macs dropped internal floppy drives. Mac-based labs were full of those things back around 2000.
Use virtual machines (Score:2)
Risks (Score:2)
All about risks, not just the fact the device is RS-232 only, but can the manufacturer support the equipment and if it fails whats the cost to the business while the machine is down.
Sure we can all get 486's with ISA cards if the device needs connectivity to the outside world, but the device of that is a business risk and needs Mgmt to be aware of the issue.
I've had a parts carousel system go down for weeks while we replace gearboxes, made worse by a switch from AC to DC by the manufacturer. Costs to the bu
Some observations... (Score:5, Interesting)
Here are some observations about why the problem isn't as difficult as you are making it out to be.
First and foremost, for older PLC hardware, the PLC hardware was considered to be the valuable part, and the software/drivers were considered to be overhead that they had to have to sell the hardware. So most of the serial protocols for these things were well documented in order to reduce support costs. In general there was either reluctant free support for their software/drivers, or you paid a fee per incident. If support contracts were an option ... you are unlikely to have kept the payments up this long. So you will likely be writing some code, but you will likely have documentation with which to do it.
Second, the FTDI drivers are crap. They leak kernel memory in Linux when you unplug them while the device associated with them is open. They also do this in the Windows Drivers, and because Mac OS X is religious about its encapsulation model in IOKit, unplugging them in Mac OS X while the device is open generally leads to a kernel panic. Almost all the USB-to-RS232C/RS422 adapters use chips sourced from FTDI, or use clones of the FTDI chips so they don't have to actually write their own drivers. Rampant code copying between vendors is my suspected reason that most of these vendors refuse to document their hardware well enough that an Open Source driver without the bugs could be written. You are unlikely to be happy with USB fobs.
Third, 9 pin RS232C is frequently not enough for a lot of older devices. The RS232C specification allows external clocking of the signal, but these pins are not present on the 9 pin connectors, only on the 25 pin. Additionally, there is out of band signaling that is sometimes used on other RS232C pins that aren't as frequently used that can be necessary. As you are with a printing firm, if what we are talking about here is an old Linotype or similar machine, you are likely to be SOL without full 25 pin RS232C. You should be happy that it isn't an 8 pin DIN cable from an old Mac, since at least you get the RI pin on the 9 pin connector.
Fourth, terminal servers often have these issues, in spades. There are a number of terminal servers where, if you have a blocking outstanding read on the serial port, outgoing writes are blocked until the read completes or times out. They basically expect that you will poll, or that all your communications over the serial port will be synchronous (i.e. you will not end up with output to your Wyse-50 until after you have input something). I can name a number of vendors with 8-port serial cards that have this issue. On the plus side, it's a driver design bug, so if you are swilling to use your own driver, or are willing to go Open Source OS, this is typically not a problem, but you will end up screwed by Windows and Mac OS X -- but a Mac OS X subclass of the broken driver is easier than an entirely new driver written in windows. Computone 8 port cards used to have this problem a lot.
Fifth, and finally, with USB dongles, it's frequent that the modem control signals are borked up. What I mean by this is that until the pseudo tty USB driver on the host side of things is opened, then the pins on the RS232C side of the adapter are floating in an indeterminate state which depends on the USB fob firmware, and is frequently not where you would want e.g. DTR or CTS/RTS or other signals hanging out for an idle serial port. This can make older equipment Do Things(tm), and the oly real remedy is to get the port open, set the signals right, and THEN plug in the serial cable. Generally, this means that you get to have two sets of signal state for setup, in addition, since the line buffers in some of the older devices are not optoisolated, and on those which are, the optoisolation can blow if you immediately apply voltage before ground, etc.. If you think talking to an old PLC is hard, try replacing an ancient Zilog UART on the damn thing.
Re: (Score:3)
That hasn't been my experience. I've been doing RS232 since the early 80s, and I've run across very few devices from that time period that use more than the minimum three.
What I have seen for devices that use the other signals is that they'll use them differently. For instance, the original RS232 spec uses RTS/CTS differently than they're used today. Also, pins will be used incorrectly; I have a computer in my garage that uses DTR for f
Re: (Score:3)
And 9 out of 10 USB to serial adapters I have run into can't even generate the correct pin voltages... +/- 6V might work for some devices, but not all. A lot won't see anything below +/-12V. Especially the 'comms powered' type.
Re: (Score:3)
I think those devices have transceiver chips that are broken, because the RS-232 specification for the receiver certainly requires it to work with +/-3V levels - those are considered the minimum levels, in fact. Anything between +3 to +15V and -3V to -15V is a valid logic level. If you have an RS-232 receiver that doesn't work with +/-6V signals, it's broken, plain and simple. I've designed some RS232-powered devices and they obviously had to work through the range of allowed logic level voltages. There's g
Re: (Score:3, Informative)
Re: (Score:2)
This is some serious bullshit about the FTDI drivers, and I don't like them but you just don't know what you're talking about I think.
On linux you have two "ftdi" drivers: there's the open source one that's part of the kernel and it shouldn't be problematic. It's maintained and it uses the usbserial infrastructure that's used for many other devices. I can't see it having such problems. The FTDI-provided "driver" is 100% userspace and uses libusb, so if that leaks kernel resources, man, you better posted abo
USB - serial adapters are cheap and easy to find (Score:2)
Just make sure you get one supporting the flow control lines, which most cheapo adapters don't. Most industrial equipment i've worked with wont communicate without those.
20 year old antique?? (Score:2)
Am I the only one laughing at the thought something from the early 90s is now considered antique?
Re: (Score:2)
Yeah, I was just blowing dust out of a not easily replaced original IBM PC from 1982 at a manufacturing site last week, and I sure wouldn't call even that antique.
Serial ports are a pretty easy thing to deal with. In PC land it's stuff on old ISA cards that are the real nightmare. One of those is what's keeping that PC alive, and we can't even replace the system with a newer model because the software is only timed right at 4.77Mhz. I'm just glad I don't have any MCA bus hardware to worry about anymore.
Re: (Score:2)
It should be eminently doable to software-simulate it on modern hardware. Simulate everything including custom hardware they have.
Re: (Score:3)
Am I the only one laughing at the thought something from the early 90s is now considered antique?
Ha, darn kids probably can't fathom the idea that there were real computers in use by companies and organizations before those flashy single chip microprocessor based PCs were all the rage.
No mention of minis like PDP, VAX/VMS (RIP DEC), CDC Cyber (12-bit bytes [wikipedia.org]), Data General [businessweek.com], or IBM & Unisys mainframes.
Thankfully there was at least mention of Zilog's Z80, terminal servers, RS-422/485, and green screens.
Bunch of whiny kids. Next they'll complain their first automobile or hand-me-down cathode ray tube co
Re: (Score:3)
The software JPL uses to navigate all of its space probes was written by Dan Alderson, [wikipedia.org] who died in 1986. Why haven't they replaced it? Better yet, ask why should they replace it when it works so well. So far, the only failure it's had was when somebody screwed up a measurement conversion, and you can't blame the software for that!
Re: (Score:2)
One thing to try (Score:2)
But where I could I replaced them with more modern hardware and software. Sometimes I'd have to write the software myself but it got done.
What about a terminal server? (Score:2)
what's the problem? (Score:2)
Scavenging.. (Score:3)
I had to support a manufacturing company 15 years ago that was using (at the time) 15-20 year old gear. I did it by scavenging and making it myself. Robot needs a new SSDD floppy drive? Flea market Commodore. RAM in the Soviet S100 clone going bad? Take apart a broken synth. Winchester drive controller going tits up? Drive around and look at all the junk bins of every computer shop in the county. Need to move a bit of kit but now the non-standard 45-pin cable is too short? Clip the ends off and Radio Shack them to RS-232. I also swapped a lot of gear around; The DOS machine that was used to program one robot was gradually upgraded from an 8088 machine to a 486 as I stole parts from it to keep the CP/M-86 one running.
The other thing I did a lot of was preventative maintenance. Blow out the dust, check the power supply, clean the disc drive, make sure everything is well seated. Switches got lubed, cables checked for faults, and media replaced.
one solution: piles of old crud (Score:2)
the way they supported old lines at (major environmental controls company you've all heard of) was to keep all the old 286 machines and line printers in a back room the size of an 80s living room, and repair, repair, repair. label printing for boxes on the production line was old Printronics machines, which was the big headache.
Industrial Ethernet Book (Score:4, Informative)
Buy lots of X40 series ThinkPads (Score:2)
They are cheap, almost indestructible, small, low-power and ancient enough to comfortably run any legacy application out there, even under pure DOS. Should one break (which is, in itself, rather unlikely even for heavily used units), full service manuals are available and having lots of them means easy replacements. They have traditional, hardware RS232 and LPT ports, one of each. As long as you need a single machine for a single PLC, X40s should be one of the best tools for the job.
Support for old software should be required. (Score:2)
Vendors, such as Apple, Microsoft, etc, should be required to continue to support older software in their new hardware and OS releases.
There is no excuse, except greed, for them to drop support for Classic, Rosetta, PPC, etc. The new hardware, even a lowly iPodTouch, can easily emulate the old systems by orders of magnitude. There is a tremendous amount of not just mission critical software such as the above article discussed but also simply good software like what came out of the hay-day of educational sof
Re: (Score:3)
Windows98 VMs (Score:2)
Re: (Score:2)
Re: (Score:2)
What doesn't DOSBox have that games don't need but business stuff does? Usually games are those things that require very good compatibility, and DOSBox is perfect in my experience...
Re: (Score:2)
Re: (Score:2)
Re:Please (Score:5, Interesting)
Actually, newer SVN + patches builds for DosBox go much further than that:
http://www.dosbox.com/wiki/SVN_Builds [dosbox.com]
The best one, if you ask me, is the SVN Daum build (alas, their website is down at the moment). To quote its set of difference to Vanilla DosBox:
Description: The Windows build incorporates Direct3D with pixelshaders, OpenglHQ, Innovation, Glide, zip/7z mount, Beep, NE2000 Ethernet, Graphis user interface (menu), Save/Load states, Vertical sync, CPU flags optimization, Various DOS commands (PROMPT, VOL, LABEL, MOUSE, etc) and CONFIG.SYS commands (DEVICE, BUFFERS, FILES, etc), Continuous turbo key, Core-switch key, Show details (from menu bar), Nice DOSBox icon, Font patch (cp437), MAKEIMG command, INTRO, Ctrl-break patch, DBCS support patch, Automatic mount, Printer output, MT-32 emulation (MUNT), MP3CUE, Overscan border, Stereo-swap, SDL_Resize, MemSize128, Internal 3dfx voodoo chip emulation, etc.
I emphasized the important bit. What these two little words mean is the this DosBox build can not only emulate a DOS printer to dump stuff into various output formats (PNG, PDF, etc.), but it can also pass along the output to a Windows printer driver (which allows you to print to any USB printer) as well as use a real parallel port on your computer to let the DOS talk directly to the printer.
I know at least one company that is using this DosBox build to support printing out of a 20+ year old billing software.
Re: (Score:2)
By the way, here's a working link for those who wish to download this version of DosBox, while the original website is down:
http://www.emucr.com/2013/02/ykhwongs-dosbox-svn-daum-build-20130205.html [emucr.com]
Re: (Score:2)
This link leads to a maze of adware and shit. What the hell?
Re: (Score:2)
I finally got this link to work.
http://www.sendspace.com/file/gpof0m [sendspace.com]
Click the non-flashy download link labeled "Click here to start download from sendspace." There are a million other buttons trying to get you to click on crap.
Re: (Score:2)
Re: (Score:2)
why don't they have it print to postscript. many modern printers take postscript input so it would not be hard to have it pipe the input to the printer.
Re:Please (Score:4, Funny)
That is an awesome idea. Let us know when you commit that!
Re: (Score:3)
You're forgetting that in DOS, every application needs its own drivers for anything beyond text mode output (MDA?) and keyboard input, so there's not a single printer interface to emulate - ideally, you emulate the more popular ones.
Re: (Score:2)
But DOSBox is itself an application and does not have to output the same stream as the applications it contains.
Re: (Score:3)
Ah, of course. Makes perfect sense - the one thing no game needs but every business user needs...
I can't blame them, I would also avoid touching anything printer-related with a 3,048m pole if possible. I guess it comes down to emulating HP LaserJet and whatever else was commonly supported at the time, similar to what's currently done with sound cards...
Re: (Score:2)
Networking.
Re: (Score:3)
DOSBox can't handle Control-Break, which was used an awful lot (for good reasons and bad) in the DOS era.
See my post from further up in this thread where I've linked to the SVN Daum build of DosBox. Among other things, it contains a very good "Ctrl+Break" patch that adds that particularly little oddity with almost 100% accuracy.
Nowadays, the SVN builds of DosBox can do so much more than the Vanilla DosBox, it's no wonder the maintainers can't decide which of those patches to add to the mainline first.
Re: (Score:3)
The beauty of OSS is that if it doesn't work you can add support yourself. And if you lack the technical expertise, pay someone to add the support for you.
A few years ago I was asked to organise a new PC to replace a failing vintage laptop that connected via rs232 to a cnc machine. The problem was that the program didn't seem to work on anything else. DOSBox didn't work initially because the program used api calls that were considered obsolete when DOS2.0 came out. DOSBox had support for those calls but it
Re: (Score:2)
Stop mixing OSS with "source available" software...
Re: (Score:2)
Stop mixing OSS with "source available" software...
I'm not sure what you're getting at here... DOSBox is GPLv2, so is OSS by any definition of the TLA. A source available license doesn't necessarily allow you to make changes to the code so obviously I wasn't referring to that.
Re: (Score:2)
Those often run into problems. Often when using those I have had to fiddle with settings. Some software has limitations as to which port the device needs to be plugged into. Yes you can reroute but thats part of the fiddling. Getting a stack of old laptops with rs232 ports has always been the most reliable way I have found. Sadly ensuring you have enough to last the life of the device your communicating with can be an issue.
Re: (Score:2)
Oh, God! That makes me feel sick. We had messes like that when I started working at this company. There are exactly two of them left, and one of them is being dismantled to be carted off to the junk yard. The remaining one is rapidly becoming so expensive to maintain, that no one can justify keeping it around.
We'll still have ladder logic for a long time to come, but no more of those freaking tangled spaghetti wire boards!
Re:Consider yourself lucky (Score:4, Interesting)
It is a case of the 'right tool for the right job.' In some cases ladder logic is still the best choice. Running interlocking or normal controls like PID and so forth in ladder makes a lot of sense. Sequential function chart can be useful too, but tends to be overused by IT types who get cornered into control and have no clue what they're doing, as does script. Basically, what I'm saying is if we ever throw out ladder, it means we're being pretty thick. Ladder has a place and makes a lot of sense from the process POV, throw too much of it out and you're being stupid.
Naturally, put the 'hardware' ladder system into a suitable PLC that can do SFC as well as ladder and the scripting language of your choice, but don't throw out the logic. That is often still the most logical solution and IT types who think ladder is obsolete should honestly be shot at dawn for the bastards who create un-maintainable messes of spaghetti code that they are. Siemens programmers are the worst culprits here.
Re: (Score:2)
Maybe I phrased that poorly - my complaint isn't the logic, but the spaghetti wire boards. Yes, we'll have ladder programs for a long time to come, because it works wonderfully in the type of application that it was designed for. But, it's SO MUCH simpler to work with in an ActionLogic or comparable PLC!!!
Re: (Score:2)
I would really hate to have to deal with those boards, or even the massive relay logic banks that they used to use. You do have my sympathy....
I have worked with a lot of PLCs, but never action logic. Always curious, how do they compare to the Allen Bradleys and Omrons of the world? I am not tied to any particular setup, except I do have an abiding hate for the bloated mess that is Siemens.
Re: (Score:2)
Not even. Our data center had an irreplaceable piece oif software that was not Y2K so they just declared that 2000 = 1970. It was finally replaced last year (1982).
Re: (Score:2)
You know, when i was new to the industry, I would have thought you were full of crap.
But now I find that sadly plausible.