The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I almost managed to read that. Care to rework that second sentence?
There's hardly any purpose in hanging on to dead hardware, especially something that old.
I was hit by nostalgia a few months back, and had been looking at local ebay equivalents to reacquaint myself with a Commodore 64 (which I grew up with). Fortunately some company managed to put together a minified version (think Nintendo's own NES-mini and SNES-mini from last year) which can use the same disk images as emulators (well, it is, itself, an emulator).
I've tinkered with all the C64 emulators before, but having this in the "right" form factor, with a functional joystick and all, managed to capture my interest over the holidays for far longer than emulators ever have.
First thing to check is the power supply, on tech this vintage the electrolytic filter capacitors are the first things to go: they will either open circuit or short out, neither is good for the electrons in there.
If the power supply passes the test then things get a bit more interesting - more symptoms on "not functioning" will be needed
We have a command line app we run to import data from "foreign" databases. Each foreign database provides its own web service. We import the data in one of four databases, depending on what environment we're in, but we can redirect the imported data into and of the four databases by a command line switch.
We use the database to determine how the app runs via a table of configuration settings. There are also arbitrary command line switches that let you change some (but not all) of the values, however not all of the command line switches are handled through the appconfig object (even though they might override a value retrieved from the database.
I'm almost done with a re-write of that section of code that:
0) Pulls config settings from the database (as before), but only for the specified program type (foreign database source)
1) Allows ANY of those values to be overridden, because I use reflection to get the appconfig object's property names, as well as a generic SetValue method.
2) Produces a program type-specific help screen (if the command line args are something like "/progtype /?"), or an app help screen that describes all possible arguments (again, using reflection for the property names and their default database values
It's pretty impressive, if I do say so myself.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I write a lot of command-line utilities, some including some stuff similar to that.
However, I _never_ use appconfig. Some do use a custom XML file designed for them.
Your point 2 reminds me of VOS.
I haven't advanced my command line parser to that point though. Even many features of OpenVMS haven't been added yet.
One of the more recent features I added to the parser is the ability to set environment variables to hold commonly-used switches.
For instance, my TFSutil expects a /URL switch (which rarely changes), so
and the command line parser treats it as if it was included on the command line. Slick as snot.
It's always cool when you get a chance to work on something and feel like you've done a clever job of it.
I got to do that last year for the first time in ages. We were making an "evaluation kit" to show off some new hardware to potential partners, and I was charged with producing the app to run the thing. I could have cannibalized an existing app, but it would have been a chainsaw job and would have looked like it. Instead I rolled up a new app from scratch. Not only did the new app look good, I got it done before the hardware was ready, which almost never happens.