I keep seeing posts on Facebook and stories on websites about how Microsoft Windows 10 is getting installed on people’s system without their permission.

Nope. Wrong. Ain’t happening.

You may have heard that Microsoft lost a lawsuit about this, or that they were “fined” $10000 over it.

Nope. Wrong. Didn’t happen.

Yes, there was a lawsuit. Microsoft was sued by a California real estate agent in over this and settled out of court for $10k. They didn’t lose the suit in court, and there was no fine.

The bottom line is, if Windows 10 is getting installed on your system, then it’s absolutely because you gave permission. The problem is that people don’t pay attention and that granting that permission may have already happened long before the upgrade actually happened.

The Windows 10 “Update”

A lot of the controversy here is because before the upgrade actually takes place, Windows shows the user a message, like this:


If you actually bother to read it, the message is very clear. The Windows 10 upgrade is already scheduled to occur on the date shown. This update is scheduled automatically because of the Windows Update settings on that machine. Settings which you, at some point, had to say “yes” to.

But I Closed The Window Without Clicking Upgrade!

Some people are making the argument that clicking the red “X” at the top right corner should close the window without taking any action.

The problem with that argument is that’s EXACTLY what it does. The upgrade is ALREADY scheduled and simply closing the window doesn’t UNSCHEDULE it. In fact, the window clearly gives you an option to CANCEL the upgrade.

It’s not really Microsoft’s fault if you can’t be bothered to read the message and click the link to cancel if you don’t want to upgrade. The problem really boils down to the fact that some people are just too lazy to read a few lines of text.

The real estate agent who brought forth the lawsuit claimed to “had never heard of Windows 10” so it seems pretty obvious we’re not really dealing with a power user here. In fact, it’s rather hard to take such a claim seriously given the amount of media coverage each new version of Windows sees.

Her complaint was that the upgrade “rendered her computer unusable”. However, that’s as much detail as we get about her computer. There’s been nothing in any version of this story to indicate that there was actually any genuine problem after the upgrade. My guess is that the upgrade went perfectly fine, and that she was simply confused by the different colors and menu choices.

Not Microsoft’s Fault, But They Could Have Done Better

Arguably, Microsoft should have realized that people are lazy and that many wouldn’t read the message. And clearly, this real estate agent isn’t a particularly advanced user. When you combine these things, it’s practically guaranteed that there will be problems.

With that in mind, it’s probably a mistake for Microsoft to install the upgrade without any last-minute “Yes, please do it now” button, and in fact they’ve changed things so that the upgrade is not scheduled to happen automatically. Now the window comes up and gives you the option to upgrade, rather than giving you the chance to cancel an already-scheduled upgrade.


If you look at the documentation for the GEM AES Scrap Library, two things soon become very obvious.

First, it’s clear that the designers of GEM at Digital Research recognized the need for and utility of a well-designed system clipboard that applications could use to quickly and easily exchange data.

Second, it’s even more clear that within no more than a couple of minutes after sitting down to map out what sort of library functions were needed and what sort of predefined data exchange formats should be used, something distracted them to such a degree that they put down their engineering comp books, got up from their desks, and left the office.

I’m guessing the distraction was lunch time. Maybe the food truck rolled into the parking lot and tooted its horn.

A third thing becomes obvious soon after. After lunch was over, they never came back to finish what they’d started.

Three Functions

The GEM AES scrap library consists of three functions.

You heard me. Three functions.  Here they are:

  • scrp_write allowed an application to specify a directory which would contain file(s) containing the data being placed on the clipboard.
  • scrp_read allowed an application to retrieve the directory containing clipboard files.
  • scrp_clear function deleted all files in the clipboard directory.

Actually, I lied. The scrp_clear function was only on PC, not Atari. I can only imagine that two or three minutes into the five minute task of bringing the PC code over, the guy doing it said, “screw it — nobody’s gonna use this anyway” and went off for a long weekend.

And Yet, Not Very Useful Functions

The first problem with this setup is that it makes individual applications responsible for deciding where the clipboard resides, rather than the system. That’s simply a recipe for disaster, especially on a hard drive where you could easily end up with a separate clipboard folder for each and every application.

The next problem is that it doesn’t provide a definitive way for an application to find out if there is data on the clipboard or not.  It has to read the directory returned by scrp_read to see if there are any files there or not.  That doesn’t sound terrible at first, but there’s no mechanism for an application to be notified when the clipboard status is changed by another application.  So, as a practical matter, an application has to check again every time it loses and then regains focus.  On a hard drive system, with a fixed system-defined directory, this would be moderately painful.  With the possibility of the directory changing every single time you check, it’s much less moderate.  And that’s on a hard drive system.

On a floppy drive system… well, shit, that set of problems deserves its own section of the article.

Not Remotely Practical Without Hard Drive

Another problem can be neatly summed up in three words: floppy disk system.

Well, not so much a problem in its own right as a problem magnifier.  Trying to use this clipboard setup on a floppy disk system basically takes every problem and makes it worse. When the user has to use one disk to boot the system, another to launch an application, and yet another to load documents, there’s a lot of disk swapping going on.  So, let’s make it worse by having the clipboard on floppy disk also.  We could use the document disk for that, or we could use a separate disk just for the clipboard.  Let’s assume that last option.

Now imagine that you need to copy some formatted text from your word processor into your favorite graphics program.  Let’s step through it.

Boot system on one disk.  Switch disks to launch word processor.  Switch disks to load the document you want.  Switch disks again to clipboard floppy.  Copy/cut the text, meaning the word processor writes out one or more files with the currently selected text.  Now, maybe, switch back to the document floppy to save changes to the file.  Exit the word processor.  Switch disks to the graphics program floppy and launch that program.  Switch to the floppy with your graphics files and load your graphics file.  Once that’s loaded, switch disks to the clipboard floppy.

Now, remember what we said earlier about an application having to check the clipboard folder ever time it loses and regains focus?  That didn’t actually happen here.  The application stayed in focus the whole time, but we switched floppy disks.  How is the program supposed to know this so it can, or should, check to see if clipboard data is now available?  Should the program have to monitor floppy drive media change just to use the clipboard? Apparently so, even though that’s just ridiculous.

Anyway, let’s just skip past the details and assume the program has checked again for clipboard files.  Maybe there’s a menu item for “refresh clipboard” or something equally inelegant but functional.  So now the graphics program finds the clipboard data with the text saved earlier by the word processor.

But now there’s a new problem.  The word processor saved out plain ASCII into CLPBOARD.ASC and formatted text into CLPBOARD.WUP, because the word processor is WordUp and WUP is that program’s native file format.  But the graphics program, like every other application in the known universe other than WordUp, has no clue whatsoever how to read a WUP file and extract anything useful from it.

Data Formats

There was no problem with the idea of WordUp saving its own native WUP format to the clipboard.  The problem was that it didn’t also save the information using a more universally recognized file format. There was zero documentation to indicate anything about what kind of data could (or should) be exchanged via this whole process, or what file formats should be used.

I’m not exaggerating. When I say “zero” I mean exactly that.  The official GEM 1.0 documentation says nothing whatsoever about clipboard data formats. I would imagine the guys at DRI assumed GEM metafiles would be used for vector graphics and IMG files for bitmapped graphics, but they didn’t actually put those ideas into the docs.

And what about other data? How should formatted text be transferred? What about a block of cells from a spreadsheet?  How about MIDI sequencer data?

The answer ultimately was, your guess is as good as mine. Is it any wonder that application programmers basically ignored the scrap library?

The real tragedy of this situation is that it’s entirely a documentation problem. There’s got to be probably no more than 8 or 10 basic, simple types of data that would cover probably 95% of all clipboard requirements. If the guys at DRI, or at Atari for that matter, had written a couple of pages of documentation saying “use this format for this kind of data” then maybe applications would have supported the clipboard.

As with many other GEM shortcomings, there would be 3rd party attempts to fix the broken situation. The PC version of GEM eventually included some documentation about data formats, but it was way too late, and limited mostly to very obvious things like TXT, IMG, IMG, and CSV.  And for whatever reason this information never really circulated to the Atari side of things at the time.

The Simple Fix, Part 1

Making the clipboard genuinely useful would have been fairly simple, had anybody been paying attention at the time. The first fix would have been to define a reasonable list of standard data exchange formats. and to make sure that list wasn’t completely GEM-centric.   For example, here’s a few just off the top of my head:

  • GEM – GEM metafile vector graphics
  • IMG – Bitmapped graphics
  • ASC or TXT – Plain ASCII text.
  • CSV – Comma separated values, text file containing one or more data records with fields separated by commas.
  • RTF – Rich Text Format formatted text.
  • MID – MIDI Data

Each “standard” format would be assigned a 4-byte value like “_ASC” or “_IMG” that will be used as an identifier.  In most cases the code would correspond roughly to the filename extension commonly used.

Keep in mind that there are some file formats in common use today that weren’t around in 1984. For example, the TIFF format for graphics files was introduced in 1986.  JPEG came out in the early 90’s just barely in time for the creation of the WWW.

The choice of IMG files for bitmapped graphics seems unavoidable, yet there is a critical flaw in that IMG doesn’t allow color palette information to be saved with the bitmap.  DRI seemed to think you’d save out a .GEM metafile defining the palette, but that conflicts with another likely scenario: if your source data is vector graphics, then saving out a rendered bitmap version on the clipboard is entirely reasonable.

This is just a short simple list that serves to illustrate the point.

The Simple Fix, Part 2

After defining the basic data formats, the main thing would be to allow for the clipboard to be either disk or RAM-based.  Most copy/paste operations could be done with a fairly small RAM-based clipboard, but it would have been easily to accommodate disk-based clipboard data when needed.

The existing functions scrp_read and scrp_write are history in this scenario as far as I’m concerned.  In their place, I would have suggested a pair of functions for saving & retrieving RAM-based clipboard data.  Something like this:

int resultcode = scrp_copy( CLIPBOARDDATA *cDataSaved )
int resultcode = scrp_paste( CLIPBOARDDATA *cDataRequested )

Yeah, I know. We started with two functions and I’m proposing replacing them with two functions. Kind of ironic, but keep reading and I think you’ll agree I get a lot more mileage out of my two functions than AES got out of the original scrap library functions.


The CLIPBOARDDATA structure defines the information being saved to the clipboard or retrieved from it. It looks like this:

typedef struct
    WORD    formatCount;
    DWORD   *formats;
    UCHAR   **data;
    DWORD   *lengths;

The formatCount field indicates specifies the size of the arrays pointed to by the formats, data, and lengths parameters.   When writing data to the clipboard, it specifies how many types of data the application is saving.  When requesting data from the clipboard, it specifies the formats that the application knows how to process.  When the system returns clipboard data to the application, it indicates which formats were actually returned. Note that an application can request one format at a time, or many.

Each of the formats specified should represent the same basic data in different formats. For example, a word processor might save formatted text in its own native file format like WUP, but also using both RTF (Rich Text Format) and plain ASCII TXT.  A graphics application might save vector graphics as EPS and GEM, but also a rendered bitmap version as IMG and TIFF.

The formats parameter is a pointer to an array of 32-bit ASCII format identifier codes (like “_IMG” or “_GEM”)  as mentioned earlier.  Each code represents a single type of data, like ASCII text, IMG bitmap, etc.  The list we defined earlier would form the core of this.

The data parameter is a pointer to an array of UCHAR pointers (WORD aligned), with formatCount elements,  that point to the data.  This field is ignored as input to the scrp_paste function.

Finally, the lengths parameter points to an array, with formatCount elements, where each element specifies the length of the data items pointed to by the data parameter.   This field is ignored as input to the scrp_paste function.

The API Functions

The scrp_copy function would save data, as defined in the CLIPBOARDDATA structure, to the clipboard, in each of the specified formats. Depending on the length of the data, it will be copied from the application space to a buffer allocated and maintained by AES, or saved out as a file to the system clipboard directory.  Or possibly both.

Calling scrp_copy would cause AES to send a message to all open applications indicating that the clipboard had been updated.  (Some later 3rd party revision of GEM added a message named SC_CHANGED for this purpose but it was not part of GEM’s original specification.)

The scrp_paste function would retrieve the current data on the clipboard, if any is available in the requested formats.  On input, the CLIPBOARDDATA structure specifies the data formats the application can accept.  This allows the AES to ignore clipboard formats the program won’t be using.  On output, the structure will be updated to indicate the data formats being returned and the actual data.

The resultcode value returned is 0 for no error,  or various negative values to indicate different errors.

Do We Need More Than That?

We could stop right there and the result would be a billion times more useful than the original scrap library.  There is at least one more function which would be nice to have, though.

  • scrp_bufferinfo – Retrieve information about the RAM-based clipboard data buffer, like maximum size.

Something like this would have been easy to create, fairly compact, and it would have made the GEM clipboard a genuinely useful tool from day one.

Next Time

I think we’ll be headed back to VDI topics for next time around but it’s still up in the air.   Don’t be afraid to comment and let me know what topics you’d like!

Other Articles In This Series

July 11th, 2015 by Mike Fulton
Categories: Humor, Miscellaneous Rambling, Web Design & Programming

HTML5 has been the big new thing around the internet for about 6 or 7 years now, and it got me thinking that, hey, it’s probably not too long before someone decides that the next version is overdue.  So I have to think HTML6 is peeking around the corner.

While there’s no doubt plenty of new features that will come with HTML6, I’d like to spend a moment to suggest some new tags that I think are sorely missing from the markup language. Combined with a reasonable application of CSS styles to properly set them off, these new tags would help users convey a greater depth of meaning to their web pages, comments, and message threads.

< sarcasm > Best New Feature Ever < / sarcasm >

One of the most glaring omissions in the HTML specification, going all the way back to the original version, is a lack of any tags to indicate the intended tone of voice. And as a result, one of the biggest problems with the entire internet is that people often don’t understand when a post is intended to be taken at something other than face value.

Being sarcastic is often referred to as being a “smart ass” — usually by those on the receiving end.  However, I didn’t think the idea of a new < smartass > tag would really get too much traction.

I really do think this tag would be a huge improvement to the internet, HTML, and life in general.

< satire > Because Sometimes Sarcasm Is Too Snarky < / satire >

Satire and sarcasm are related but not quite the same thing, so they really do need separate tags. Sarcasm is usually much more snarky, more obvious, and often has an undercurrent of anger and/or bitterness so it. Sarcasm is typically expressed by presenting the opposite of the desired argument. Satire is more subtle, and more tongue-in-cheek.

On many occasions I’ve seen someone post a link on Facebook and then go off making some angry comment about it, and it’s clear that they didn’t realize that The Onion is a satire website.

Parody is a less subtle version of satire. I don’t really think we need a separate tag for it, however. Thoughts? Questions? Perhaps we should put out an RFC on this?

< flame > Bitch Bitch Bitch < / flame >

Another good tone-of-voice tag would be flame.  This would indicate a block of text where someone is going off on a rant about something.  Usually it’s a complaint of some sort, but not always. Sometimes it’s just a very impassioned response to another post in a message thread. Expect cursing, WORDS IN ALL CAPITALS, and other good stuff.

It’s worth noting that this tag is already used informally by many people, albeit in an inconsistent fashion.  It’s time to make it official!

< troll > Oh Yeah, Well Nazis So There! < / troll >

An interesting internet phenomenon is the troll. No, not the mythical creature who lives under a bridge and attacks passers-by. An internet troll is someone who makes posts or comments on a message thread of some sort which are intended to manipulate other users, to provoke a certain response.

There aren’t any specific words or phrases to watch for in a troll post.  However, invoking Nazis, communists, gay marriage, former President George W. Bush, or President Obama are all traditional tactics of the modern internet troll.  A really good troll can combine all of those topics into the opening sentence of their post. But depending on the overall subject matter, a troll’s post really could be almost anything. For example,

Batman would beat Superman in a fight

J.J. Abrams has ruined Star Trek and now he’s gonna ruin Star Wars

The Nazis Took Everybody’s Guns Away Too!

Gay Marriage is For Faggots

I apologize for that last one. Although it’s arguably true, I realize that last word is considered a bit offensive. Unless you’re British and talking about cigarettes. However, it wasn’t my intention to offend, but rather to demonstrate how being offensive is one of the troll’s prime weapons.  There’s almost always some part of a troll’s post that’s offensive to someone.

I guess I have to apologize for the first example, as well.  It should be clear to anybody paying attention that Superman could heat-vision Batman into ashes from the other side of the solar system, so really, Batman has exactly as much of a chance to win as Superman decides to give him.

The main attribute of a troll’s post is extremism. It’s extremely offensive, or extremely conservative, liberal, or even extremely center-of-the-dotted-white-line middle-road.  More often than not, the direction of the extremism more or less indicates the direction of the troll’s actual option, but playing devil’s advocate is also quite common, as the troll is far more interested in provoking a response than they are about engaging in serious discussion or debate.

As with sarcasm, one of the biggest problems with a troll’s post is that many times, readers simply don’t understand that the post is purposefully (or perhaps subconsciously) intended to be incendiary and offensive.  Indeed, one of the things about a troll’s post is that you can’t even be sure it represents their viewpoint.

< funny > Well, Maybe < / funny >

As with sarcasm, it’s not always easy to determine when someone is trying to be funny.  If this post has accomplished nothing else, it should have proved that point beyond a shadow of a doubt. This new tag wouldn’t necessarily make a bit of text any more hilarious, but at least now you would have some indication that humor was the actual intent.

I wish I could use it now.

« Previous Entries