As an external observer, it appears that certain Fair Use rights of Copyright audio have been foreclosed by Microsoft, without notice. It is clear that the Digital Millenium Copyright Act put Federal teeth into protecting the rights of music and movie publishers against people who illegal share high quality copies of their material. And, of course, it is only to be expected that something had to be done to stop free distribution of material that cost something to make and, on which, something should be earned by the originator from the sale of every copy. A Windows feature call Secure Audio Path has been around for a while that protects against illegal copying of certain copyright works by reversably encrypting the binary representation of sound from the source to the sound card driver. Interlopers hear random noise. Back in the day, you could hookup a tape recorder and make a copy of the radio station playing in your town. That was called Fair Use, and Congress mandated that manufacturers of magnetic tape put a surcharge on blank tape, as it was assumed that every blank tape would be filled with copyright material. These days, you cannot record the sound coming out of your computer's speakers, because the fear is that what is playing is copyright material. And who are you to record that? You might (gasp!) sell it on eBay. So all sound, with and without pictures, is assumed to be copyright material and is off limits to every Windows user. And without notice from Microsoft. The value of Windows to me would be enhanced were it possible for me to digitally record what comes out of my computer's speakers, which, in my lonely case, is not copyright material. But, it is no longer possible, despite no admission of that fact by Microsoft.
"I Had No Idea You Could Do That With Windows Vista" Precisely... This is a customer comment from the Mojave experiment. Only after Apple puts on a series of commercials poking fun at Vista does Microsoft set out to demonstrate Vista's new features and advantages. The initial effort in that direction was to sell the thing and let users sink or swim. Of course, Vista works pretty good. You only have to go out and buy a new computer if you want it to perform. And "certified able to run Vista" computers were sold despite the fact that Vista wouldn't run well on said computers. The user interface is something software designers pay not enough attention to, especially when they devise to rearrange an environment that has become familiary to 10s of millions of end users. Designers deign not to produce a map so that users who are used to doing something one way don't have to spend hours discovering how it is done now. And my copy of Vista for 64-bit computers does occasionally lock up.
I have decades of experience with what were called timesharing systems. Much effort was put into making each user's experience satisfying. Many users would logon to a single computer (perhaps several CPUs and a good amount of main memory). Since each user evaluated the computer's performance by how responsive it was for him, the manufacturer put logic into the operating system to ensure that user response time was minimized. That meant that I/O bound batch jobs would run, but not at the expense of giving good response to live, breathing human beings who want answers immediately, not 10 minutes from now. Comes the revolution. Now, everybody has his own computer and very few choices for operating systems. The Microsoft operating system (I think they call it Windows) can be maddeningly unresponsive when an I/O bound process (like a file backup) is running. Even dropping the CPU priority of the I/O bound job is not sufficient to make the user interface responsive. Why is that? Well, I would imagine there is a great deal of disk contention between the user interface-related work and the file backup-related work. Everytime an I/O completes for the batch job, the next-queued I/O for that job gets started from the I/O request queue. Work that gets queued from the not-I/O-bound job has no priority. So, while my file backup job (long running) is active, I can double-click an icon on the desktop and wait ... and wait for the operating system to do all the magic necessary to get the program into memory (from disk) and started executing. This problem was solved very satisfactorily in the 1970s. And unsolved when the Unix-heads started designing operating systems for the 21st century.
Well, a deal was cut with the devil when somebody decided it was better to "go for it" to permit 3rd party code to become intimate with IE internals. That's the Rich Internet Experience we've all been hearing about. Invite a stranger into your house and he may steal you blind or cause you bodily harm. And there isn't a thing you can do about it. IE gets the blame though the cause is the 3rd party whose software may well be buggy and non-conformant. But that may be because Microsoft cannot to save it own skin produce comprehensive and comprehensible documentation. That is an area that nobody in power wants to explore. But if you want to analyze the root cause, it falls close to that area of endeavor.
The advent of the Graphical User Interface (GUI) brought with it the notion that the human/computer interface is therewith so simplified that erstwhile practices, such as rich documentation and focus on usability, were abandoned. Since running every GUI program reduces to a "simple sequence" of points and clicks, one can dispense with documentation. One doesn't, in practice, dispense with documentation. One simply creates "help text" that generally isn't sufficiently helpful, but does stand in for rich documentation, as that requirement sits perpetually on low heat over a back burner. Program complexity hasn't reduced with the GUI. Rather, it has increased as screens full of icons, toolbars, scantily self-explanatory controls, buttons, and scroll bars, have become de rigeur. The user knows, more or less, what task (s)he wants to perform. Yet, the help text and the GUI fail to address tasks and how to perform them. In the bad old days, the user interface was 80-column punch cards. That meant the user had to learn some sort of language with which to communicate with the computer. The language could be simple or complex. But, documenting a language is a much more straightforward process than documenting a series of points and clicks in a GUI. Your grey-haired granny can probably poke and hope her way around the e-mail GUI. Yet some programs defy mastery given the mind boggling complexity of the GUI and the mind blowing obtuseness of the help text. Apparently, explaining how to use a program is of no concern to vendors or purchasers. End users will figure it out or seek employment elsewhere. Finally, the GUI has given us the extreme disadvantage of being unable to automate many mundane processes that heretofore were easily automated. How do you tell a GUI to repeat a process? Microsoft's solution is to have the end user learn an extremely difficult scripting language called VBA, which is completely different from the GUI and an alternative user interface that does not involve pointing and clicking. In the end, this has to do with the nature of program quality. Lots of time and money is expended trying to decode the intent of program implementers. It is not so easy.
POST /XX_WEBSERVICES_41/authenticationclient.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
Und the answer is...
9/12/2007 19:16:51 HTML page on localhost:
HTTP/1.1 400 Bad Request
Date: Wed, 12 Sep 2007 23:16:53 GMT
Ja. Ist Bad Request. Could you be more specific? Danke.
I learned to program in assembly language by observing the code a Fortran compiler generated from my early attempts at programming. Fortunately, the machine code was for a machine that was designed by engineers for engineers who code in assembly language. So the effort wasn't wasted. Programs written in C and C++ (not to mention Visual Basic) are U-G-L-Y. There is no need to suffer through them to benefit from the beauty of C# and/or Java. Of course, at some point, any programmer should gain a deep appreciation for what compilers and linkage editors do for them.
Yeah. But what about broadening your horizons? Playing sports. Meeting members of the opposite sex? Earning 120 credit hours in undergraduate school?
Grandma doesn't know from parameters. Besides, all I was trying to do was copy a DVD to a blank DVD.
I am at a loss. What am I to do?
This is Windows Vista RTM.