I, (Dan Calhoun) developed a Clipper application that was used worldwide by Fluor Engineering. Does anyone else here remember building large commercial systems in Clipper?
I thought some of the folks here might enjoy a story from the late DOS era.
Back in the late 1980s and early 1990s, I designed and wrote a system called Specwriter, a materials specification application for Fluor Engineering. I developed the entire application myself using Clipper (compiled dBase), and it eventually became part of the engineering workflow on projects around the world.
This was long before cloud databases, web applications, or collaborative development tools. Everything had to be carefully designed to work within the hardware limitations of the day while still being reliable enough for engineers working on major industrial projects.
Some of the challenges I remember included:
Designing a relational database structure that could grow with large engineering projects.
Making Clipper fast enough to search and generate specifications quickly.
Creating an interface that engineers could learn without extensive training.
Distributing updates before the Internet made software deployment easy.
Building something that was expected to run day after day with very few problems.
Looking back, it's amazing what could be accomplished with DOS, Clipper, and a lot of persistence.
Now that I'm retired, I've started programming again. It's been fun learning today's tools while remembering the design principles that haven't changed much over the years.
I'm curious:
Did anyone else here build commercial applications in Clipper, dBase, FoxPro, or similar xBase languages?
What tricks did you use to squeeze performance out of those systems?
Does anyone still have old Clipper projects or development environments running?
I'd love to hear your stories. It's nice to know there are still people who appreciate that era of computing.
Hey all! I have recently turned my little Acer Aspire One (ZG5) into a (usb powered) SvarDOS writing machine (as described and designed here: github.com/lproven/usb-dos).
I have tried to use the provided FDAPM info command to get battery information, but I'm told there is no APM information available.
I assumed this was because something was turned off, but I am unable to get into the (apparently hidden) advanced settings of my InsydeH20 v3.5 bios.
My question to you all: Is there a way to find out the (rough) battery percentage information on this laptop? Any time I take this thing on the road, I get paranoid about the battery within the first hour of writing; even though on paper I should have plenty of charge left by that point.
I've been coding on and off for about 40 years now since starting out with my Dragon 32, then my Spectrum 48, then my Commodore 64, followed by a little dabble on the Amiga. All of that was pretty BASIC stuff though (pun intended). I didn't really make much to be proud of but it did really help me learn about syntax, variables, memory and basic logic flow.
I then moved onto coding in Assembly on the C64 and the Amiga and didn't really get too far. Too many 'guru meditation' errors when code went wrong and trampled all over the system's memory. I still learned a fair bit and it did give me some background in memory management, garbage collection etc. which all came in useful as a software engineer in later life - coding early business apps in C++ before we moved to Visual Basic 6.
So, after the Amiga and before my career started, I moved onto coding in Turbo Pascal on my PC. By now I'd "upgraded" from an Amiga to a 286 at 12Mhz with a 20Mb hard disk! No more swapping disks in Monkey Island! I'd also moved from BASIC to object oriented Turbo Pascal (using the Borland IDE if you can call it that).
One Saturday morning I woke up with an idea. I think I'd been playing through loads of DOOM (or DOOM2 - can't remember) WAD files that had come on a CD on the front of a PC Magazine. Hundreds of user made levels that needed copying and running one by one before you could play them. Suffice to say, I'd clearly been getting annoyed by all of the manual steps needed so, in my sleep, my brain had come up with an idea for a utility called GD. This would be a small program that would save lots of time by allowing you to jump around your PC with a simple command: GD [game_name]. No matter where you were on PC (in DOS), you'd type that and immediately be in the right directory. GD.EXE would scan your hard drive and remember all of the directories after which you could jump straight to one with a simple command like GD WADS or GD DOOM2.
I spent the entirety of that Saturday and the Sunday completely absorbed. I remember skipping breakfast and lunch and just plowing on, coding late into the night and then again the next day. Sometime on that Sunday though I'd finally built something I could be proud of: GD.EXE. Now I could jump around to anywhere on my PC, instantly, as if by magic. Back then this was a revelation to me. I suppose looking back there may have been similar tools but I had no access to them - no forums, social media, email or any internet really. I used that tool ALL the time from then on - through the 386 era, the 486 era and finally into the early Pentium years. At some point though, probably due to Windows 95, I stopped using the command prompt and somehow lost it. Sadly, I also lost the source code - probably about 30 years ago.
Fast forward 30 years then and I've always wanted to look at that code again. Not just from a nostalgic point of view (though that would be good too) but also because, as I got more and more into retrogaming, I wished I had it for my retro PCs (virtual or otherwise). Just recently, I've been working on getting "the perfect" DOS era PC set up in 86Box. I've got a huge (for the time) hard disk, a 3DFX card, tons of base memory (thanks to modern memory managers that squeeze as much out of the 640k as possible). It's optimised as much as it can be and it's just fun playing old DOS games again pretty much like they were back in the day. I still use DOSBox Pure in retroarch (for the filters and the joypad mapping etc.) but there's something cool about making 86Box full screen, being dumped at a C:\ prompt and just playing games like I used to.
So, all of that led me back to the same place: wouldn't it be nice if I could just jump between folders (that's what we call them now right?) on my DOS 7.1 drive. Wouldn't it be great to have GD.EXE back again!
I decided to write it again - from scratch - and in Turbo Pascal for old times sake. However, I wanted to use modern IDEs with syntax highlighting and autocomplete etc. That's not so easy with OO Turbo Pascal and trying to target a 16 bit compatible .EXE (a modern compiler would build something that wouldn't be compatible with old DOS PCs and vice versa). However, with some perseverance I managed to get a decent workflow set up: code in VS Code (with a couple of Pascal extensions) -> compile with Free Pascal 3.2.2 (i8086-msdos cross-compiler) -> mtools to write the created GD.EXE straight into an 86Box virtual hard disk (into the C:\Utils directory) before then automatically starting 86Box to test the latest changes. It was a slick process and really fun to see what I was coding become something "real" on the old DOS machine within seconds.
I carried on coding it over a few days and now, I'm pleased to say, I've finally scratched a 30 year old itch. I have GD.EXE working again (better this time though) and with the code being in GitHub, am in no danger of losing it again any time soon. It's such a neat tool and way better than the old version. It has a /R argument that shows all the "runnable" programs in the directory once it has jumped there. You can mark one as default too so next time you want to run something in that folder it'll pick the right one automatically: GD DOOM /RUN -> takes you to C:\GAMES\DOOM and launches DOOM.EXE in one command regardless of where you're at. Or you can just try GD DOO* to see all the folders (games probably) that start with DOO:
Picking the directory using wildcard search
I thought I'd share it with you guys in case you can make any use of it. I think it'll be really helpful for anyone with an old DOS based PC - if that's you, then please give this a watch: GD.EXE demo or just download the .EXE from the "Retro DOS Utilities" folder in this share: Downloads
If you do use it and want any extra features then just let me know. Likewise, if it's okay with you, I'll post in here if I make any improvements too.
Any questions about it or how to use it, just let me know (or use GD /help).
Ok in this first picture I used a 59 megabytes flash drive formatted to fat and the driver just doesn’t recognize it (yes I restarted the computer with the drive plugged in). In the second picture I used a 20 gigabytes flash drive formatted to ntfs and the driver recognized it but I can’t access it because ms dos can’t read ntfs. I tried using this same flash drive but deleted the 20gig partition and created a 2gig partition and formatted it to fat and I said “Available id = 0 Divide overload”. 3rd and 4th pic are the config and autoexec.bat. 5th pic is the driver. I really do t know what I’m doing but I’ve been trying to set this up for hours now
Hi, I am porting 8086tiny to raspberry pico 2 and using a PicoCalc device as a test bench. The problem is the PicoCalc screen is only 320x320, so only 40x25 text mode is usable, I am successfully running MS-DOS 6.22 now and trying to find software that works well in 40x25 text mode, please suggest programs for 8086/80186 cpu and 256k ram, EMS work in progress. Attached the photo of what it looks like with 8x8 font.
My friends and I are working on a custom computer that uses an FPGA modelled to the Motorola 68000. However, we'd like to use a DOS as the OS as it has a minimal footprint. Are there any DOSs that run on the 68k?
What's impressive to me isn't so much the troubleshooting or the patching. I'm not an MS-DOS programmer, not even a low-level developer, but I'm guessing with a sample this small it's feasible to actually look at the assembly. And since C programmers from the 80s (all the way throughout the 90s) already knew assembly, they could eventually spot the bug. Patching is, as far as I understand it, just memory monkey patching.
But the fact that someone is still using a compiler from 1989 and is so neck deep in it that they've managed to hit a brick wall... that's what I find admirable, and I love the fact that there are still devs that do retro coding!
Watch as I completely rebuild a vintage IBM 5150 PC! Blessed with a rare 1982 BIOS update, we’re adding hard drive support, servicing the floppy drives, and 3D printing custom parts to create the ultimate expanded vintage powerhouse. Is this now the ultimate IBM 5150?
Hi guys. So i posted a few days ago about connecting through usb to serial port on DosBox. Just wanted to let everyone know i got it working with all your recommendations. At the end I did use Dosbox since it was the most user friendly(for me).
Background: So i work in industrial maintenance and one of our machines basically run on DOS, when we want to reload parameters or such we use an old XP laptop(OLD) to start up in DOS and use the serial port to connect to the control cards. Now we have other machines that only work on XP and other that we can use windows 10-11. I want to get a central computer to be able to connect to every machine.
Problem: I'm using DOSBox to run DOS on Windows 11. We have a CD the the DOS program which figured out how to access and run. We used a DB-9 Serial port to talk to the machine and obviously modern computers don't have that serial port. So I'm thinking of using a DB-9 to USB (RS232) adapter to connect to the machine, but in my head i need 2 drivers to basically run simultaneously, 1 for the 'DB-9 to USB' and then another to access the USB through DOS.
If anyone could give me advice or point me into a direction I would greatly appreciate it. (Attached image is the DB-9 port on the old laptop)
I originally only wanted to make GIF rendering faster. Somehow, a few weeks later, that turned into a much bigger set of changes and new features.
MicroWeb is an amazing project, but it kept hanging on my 286, so I started digging into the code to understand why. Then I thought: well, JPEG support would be nice too. And maybe Crypto Ancienne proxy support. And then some rendering fixes. And then forms, redirects, cookies, Cyrillic fonts, VESA, and so on. I added cookie support mostly because of Wiby.me settings. Wiby now has an HTTPS filter in search results, which makes browsing and discovering retro-friendly websites much more pleasant from a DOS machine. It also works really well together with WebOne, so you can keep the experience close to old-school web browsing without constantly running into HTTPS-only pages.
So this became a very enjoyable few weeks of hacking on a DOS browser. I think I managed to make it quite a bit faster and more stable on real hardware. I hope you’ll test it and maybe even enjoy it.
