You cant really do this with CRT's because of the gases contained in them.
Um... what gases? A CRT is a vacuum tube. If you crack the nipple, it sucks in air from outside. (and then becomes inoperative) If you know something that I don't, then please link to this new information. The only problem with CRTs is that the glass contains lead, to shield bystanders from the X-rays that get generated.
Also CRT's are prone to keep a charge long after they've ever been used.
For days, weeks, maybe months. But not for years, and it's unlikely that you'll find any that have even been plugged in in years. It is also not hard to discharge the CRT with some wire and a 1 megohm resistor.
I'm not saying it happened here, but many people do not understand that you have to put things in appropriate packaging for the machines to process.
This. I have seen too many things shipped in inappropriate packaging. Just a few months ago, I ordered a $400 replacement board for some equipment, and the company I ordered from took the sub-box (the one made of inferior East Asian cardboard, and meant only to be used to put the item on a shelf), slapped a label on it, and gave it to USPS. Hey, it's a box, right? Just ship it! It arrived very battered, and the mailman basically ding-dong-ditched it (I was expecting it, and by the time I got to the door, he was already back in the truck!) The only thing that saved it was its anti-static bubble-wrap packaging.
I have also received a box crammed into another box with no padding on the sides, when the original box was itself part of the value of the item. It was literally slid into another, slightly larger, box with zero clearance on five sides, then foam peanuts poured into the top nine inches or so. Naturally, the box landed hard and a bottom edge was crushed. Just putting a couple inches of foam peanuts on the bottom would have been enough to save it.
I do want to use a better-C-than-C. C with classes just for the sake of structuring code more coherently. C with better type checking rules. C where I can release a semaphore on any exit from a function. A stripped down C++ that more resembles Cfront without all the newer fluff.
That's the basic point of Embedded C++. (Actually, that's not true, the real point was that in the '90s, companies making C++ compilers were having trouble implementing things like templates, and EC++ was an attempt to give them more time.) But if you disable RTTI and exceptions in the compiler options, avoid using anything that loves to use memory allocation (bye, bye, STL) in favor of your own fixed-sized memory pools, completely ditch unnecessary I/O crap (iostreams, locales), use the leanest run-time libraries (no floats in printf, etc.), and avoid going nuts with templates, the resulting subset of C++ can be quite lean. It also isn't hard to mix with plain C code as long as you declare things extern "C" when necessary.
It just so happens that mbed uses C++ this way, and it works quite well on small micro-controllers. The big thing that C++ does is to allow a class to be used as an API for a hardware device. All the details of a device's state are hidden inside its object, and similar hardware with different details can have a new class written for it with no changes to the code that uses it.
The trick to using C++ in embedded is to throw away stuff like the STL that depends on memory allocation, and the ivory-tower stunt crap like iostreams. Even templates are generally bad because they cause code size to explode by compiling a new version of each method for every class that uses them.
Basically, do what mbed does and use it as "C with classes". If you declare global objects for each I/O device, the class declaration then becomes an API for the device, and the object hides all the internal state. The operational details of it can be rewritten for a similar kind of device, without changing the code that uses it. If you do things right, you might even save some bytes. C++'s inlining of method calls when there is no ambiguity also contributes to the efficiency. It is also much easier to use virtual methods than to deal with the twisty function pointer syntax in C, plus you only get one set of virtual function pointers generated per class in the vtable, and can't use the wrong function pointers by accident.
I had a "holy shit how did I even hack this" moment once in the early '90s. The place where I worked used a time reporting app written by some guy. He had put a time bomb in it where if they didn't pay him every few months, it would stop working. It was written in some kind of database system, maybe Fox Pro. Whatever it was had a byte code interpreter for the scripting.
I managed to come up with a one-byte patch for it using only DOS DEBUG. I recall that at some point I had discovered a certain byte code (0x54?) was a conditional jump in the byte code interpreter, and I was just able enough to see the check ahead of printing the expiration message. I also recall that something about the display went a little wonky (maybe it always said expired or something) with this patch, but it worked.
Even in 201x I've still done binary patches. A few years ago, some legacy code needed to be used for a new customer... in Mexico. We were making a completely new system, but needed to install our legacy system for a pilot test until it the new system was ready. The thing is, Mexico didn't have people sweet talking Dubya into thinking that changing the Daylight Saving Time dates would save energy (it doesn't), and the legacy system (which I could never figure out how compile) only used the new DST dates. Except that the code actually still checked the year before choosing the DST date. So I came up with a one-byte patch (an operand in a 68HC12 instruction!) that changed the year check to 14000ish by tweaking the high byte.
If you didn't use Apple II or Commodore, you also had to cut an index hole. This was considerably more complicated. I eventually would just slip something protective into the disk and slash out a square with a razor blade. Then repeat for the other side.
And, for what it's worth, you can't read the other side with a double-sided drive for two reasons. The obvious one is that the track spins backwards (as if that would stop a dedicated Catweasel user), but the less obvious one is that the second side is offset by 2 tracks, making it impossible to read the first two tracks.
Punching an HD hole on 3.5" floppies was a bad idea, because HD had different magnetic parameters. It's like the old chrome cassette tape thing. Genuine HD floppy disks were total crap in the later years anyhow, which probably helped encourage people to stop using them.
Writing software is more fun than working.