On Friday, 16 January, 2015 14:05, Simon Slavin <slav...@bigfraud.org> said: >On 16 Jan 2015, at 9:01pm, Keith Medcalf <kmedc...@dessus.com> wrote:
>>> Not, at least, when your database contains string data with unusual >>> characters that Windows feels like it should translate for you... >> I think that pretty much limits one to the 7-bit ASCII character set >> ... >Why on earth would an operating system programmer bother to put any >translation into piping ? Piping is really just a demonstration of how to >use stdin and stdout. I'm mystified. They wouldn't. However, we are not talking about a real Operating System designed by real System Programmers -- we are talking about Microsoft Windows, which contains a lot of disparate code sources all stuck together with LePages White Glue which maintains backwards comptibility with, oh, DOS. DOS implemented the pipe "|" operator in "a | b" as "a > tempfile" followed by "b < tempfile" -- because it could not actually run two processes at the same time. This meant that the pipe was 8-bit clean. This method of implementation of pipes stayed the same until OS/2, which was the first truly multitasking descendant of DOS (more or less). It implemented the interprocess pipe as one would expect -- by opening an OS 8-bit clean anonymous pipe, then cloning the input/output handles onto stdout and stdin of the two processes respectively. Then along came "OS/2 New Technology" in which Microsoft renaged on the Joint Development agreement between IBM and Microsoft, and renamed the product "Windows NT". Under the termination agreement, the codebase became the property of both IBM and Microsoft. However, under the JDA the codebase contained quite a bit of patented and proprietary IBM code and technology. Microsoft was given a few years to replace all the IBM technology with their own (so, for example, the "Microsoft" re-written versions of all the DDE and IPC mechanisms, which were patented and proprietary IBM based on their experience with "real computing systems" where renamed COM/DCOM/ActiveX) in various flavours and re-implemented by Microsoft. This eventually became Windows NT 4.0 (which is I believe the first version of "OS/2 New Technology" which was devoid of all the IBM code and partial workarounds. Microsoft programmers, being the rather simple folks that they are, re-implemented many of those IBM bits with rather simplistic and crude implementations and others, that they couldn't figure out how to do at all such as priority-based pre-emptive multitasking, they simply replaced with much simpler implementations derived from their DOS and Windows 3.1 GUI. Without actually redesigning and fixing those broken design decisions (like the one where they decided that the screensaver -- when triggered -- should be the highest priority task in the system), current versions of "Microsoft Stuff" still operates from this old ill-concieved design basis. They still haven't quite figured out how to do the "pre-emption" part of multitasking yet, but they are getting (very slightly) better. If Microsoft eventually gets around to fixing their busted dispatcher, their busted I/O systems, and their busted process isolation (which they deliberately bust in order for their other software to work) then they will have a "real" Operating System -- probably somewhere around Windows 25.6 at their present rate of progress (although, of course, that Ballmer idiot really screwed things up, and their propensity for doing really assinine things, makes it more likely that they will never be able to produce anything that would qualify as an "Operating System" in the true sense of that word). Anyway ... The pipe operator connects the "output" from one program to the "input" of the next. On Windows both stdout (to the console) and stdin (from the keyboard) are "cooked" streams. Using the "|" operator connects these two cooked streams together (meaning that Windows will perform the same output translation as if it were outputting to the console, and the same input cooking as if the input wre coming from the keyboard. Contrast this with the "file pipe" operators < and > which cause a file to be opened and then that file handle to be "cloned" over top of the stdout or stdin handle -- meaning that the "console cookery" is no longer in effect -- you now have an 8-bit clear channel. Real Operating Systems written by real System Programmers implement the pipe | operator by opening a pipe (which is an 8-bit clean communication channel, like a file) and then cloning the handles to the appropriate process stdin/stdout handles, thus the kitchen is disabled and the I/O is not cooked. It would be nice if Windows had a "treat all I/O as 8-bit clean" switch and you could disable the cook/kitchen, but you still cannot. Just as there is no switch to let you, with one go, switch Windows into "Intelligent Person using a Computer to Compute" mode rather than "Dithering Idiot Magical Behaviour, Insecure and Unsecurable" mode -- you still have to make several thousand setting and registry changes manually to accomplish this task -- and it is one of the things that makes configuring a useable Windows system a many days long process -- not to mention that Windows tries at every turn without bidding to undo the changes you have made and switch back to "Magical Mystery Insecure and Unsecurable Mode" without notice every time you install a patch or update and sometimes just whenever it feels like it, making maintaining Windows Systems a continual battle between the forces of idiocy (Microsoft) and everyone else. The long and the short of it is that the interprocess pipe in Windows connects to cooked channels because it never occurred to anyone at Microsoft that this was undesirable and irrational. Of course, it could also be that some piece of Microsoft Crockery (Microsoft Bob perhaps) requires this behaviour in order to function, and therefore they do not want to "fix" it. --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
