Site Sponsors:
Microsoft Ignorance 
There we were, watching the bandwidth.

The client complains that the time is always around 8AM... people are settling in at work ...

10 ... 9 ... 8 ...

Look Bill... no more network!

What am I talking about?

Why, our inability to be able to readily manage our own computers, anymore! (*)

Yea - we can schedule each and every computer to check for updates within no more than a few days of their availability... but we can no longer turn it off?

... Hey Microsoft: whose computer is it, anyways?

Lamentations


In times past I would routinely turn updates off while traveling. Especially when traveling abroad. Why? Because in the XP days I have had airport servers use the operating-system's update as a vector to install viruses on my computer. Indeed, if you can inject your own Certificate Authority (CA,) into a browser, then hijacking such things is relatively easy to-do.

Moreover, ignoring the fact that there are some updates that will break both hardware-drivers, as well as corporate software, Microsoft's decision to prevent us from managing our own computers demonstrates three (3) things:

THING ONE: The first thing demonstrated is that Microsoft no longer had the brain=trust to adequately manage a belated software-update patch-farm.

Of course, Linux does so with impunity. For free.

Not only is the software development brain-trust logarithmically failing in Microsoft (as everywhere else throughout America,) but one must remember that the majority of Microsoft's updates are fixing software B-U-G-S, people.

Bad software. Bad testing practices. Back-doors, security exploits & holes. Corporate maleficence!

Even the simple & highly testable GAME of Minecraft - so elegantly and operationally handed-off to Microsoft developers - has since become a frustratingly bug-filled nightmare to play!

Such easily avoidable defect nightmares make one wonder - when it comes to quality - if some teams have simply been cursed?

THING TWO: The next thing demonstrated by the Windows 10 developers is that they are completely ignorant of the configurations management requirements of all modern corporations.

While crafting day-sidestepping installation policies are possible, a llot more than corporate visitors use complementary WIFI networks. --Since the advent of Windows 10, all are so slammed by the sheer plethora of now-mandatory Windows updates that most networks are thrashing these days... completely unusable!

And don't get me started about the toll automatic updates is taking across conference halls, at home, & in classrooms: Automatically updating computers in a wireless-networking situation is pure lunacy!.

THING THREE: Using the term "HIDE UPDATES" demonstrates a complete lack of understanding of the English language. Just like ignoring 25 years of Common-User Access conventions, in a time when a "senior engineer" is defined as having a mere 3 years of industry experience, we must marvel at how much money Microsoft must be saving ... while thousands of non-native others so obviously ruin what was once the most-used set of soft-wares in the world.


p.s.


Like Apple, Microsoft wants to be able to spy upon their users too.



(... Create a cookie-tracking Account ... Give them your reverse-searchable phone number ... Put all of your important documents in THEIR cloud... just so THEY can gather clandestine data on us as we SO COMPLACENTLY loose control over our own 'stuff!)

In the "Doh!"


Yet Apple could get away with such things (a mere 10% of the bandwidth, people!)

But at the moment there are A LOT more Microsoft computers, friends!

Therefore (it is sad to even have to point this out to them!), Microsoft updates will suck A LOT more capacity from the corporate pipes.

Even more interestingly, when it comes to spying on their own users MS does not even have the brain-trust to spy on folks properly!

Such is why - if you shut-down, unplug your Windows 10 computer from the Internet (don't forget to disable that home WIFI on those laptops!) that you will receive those "cannot spy on you (sic)" network messages.

Tragically, even when clicking on the resulting "more info" messages as directed, our quest for more information is completely ignored by Windows 10. (I recommend that you use 'view logs', instead? --If any type of corresponding notices are in the Windows log-files at-all, they are usually a lot more cryptic... but we might get lucky when we 'google for some type of understandable explanation...)

... I guess that they will fix THAT later, too?

Solving the Problems


In the mean time, might I suggest that you make a healthy donation to the Free-dome Software Foundation?

After that, then P-L-E-A-S-E contact your congressional representative and ask them - in a time when 1 in 7 Americans are having problems merely finding food - why our government is allowing American companies to use so many foreign workers?

If foreigners need American jobs, could their nations not petition our government to allow them to join the Union?


Statehood worked out rather well for Hawaii!

Who Cares?


Indeed, the fact that companies such as Hewlett Packard & Disney make their billions in America does not prevent their imported-executives from loosing any sleep as each farm American jobs out to (in the words of the guilty HP Executive) "less expensive" nations!

In the 1960's '70's & '80's, companies with no loyalty to the American worker would have been boycotted... What has changed?

(*) By the way: Even after I downloaded the software, I was unable to "hide updates" for anything. My advice now is that - when traveling - to simply not allow Windows 10 to connect to the Internet.

Caveat User!


[ add comment ] ( 355 views )   |  permalink
Java IPC and Microsoft Windows 
Since the 1970s, folks in the C World have long been enjoying the benefits of "piping" things between processes. Piping is easy, it is fun, and (with a single invocation work-around on Microsoft Windows) piping works pretty much the same everywhere.


While we have been able to start, read, and pass information to other programs on Java for awhile now, everyone knows that - far from "Write Once, Run Anywhere", using Processes under Java can be a very platform – let alone operating system process - specific undertaking.

Process Woes


Interestingly, the first cross-platform IPC problem has very little to do with Java. When working on 'Windows, the most frequent errors encountered often simply have to do with (1) where the program is located / invoked, as well as (2) how we use Java to manage the input and output streams.

Location Matters


For those who are new to programming, the first thing to do is to note that some of the commands we use at a terminal (or "shell") are built-in. Others are external. Hence whenever we type "ls" on Linux, or "DIR" on Microsoft Windows we are not executing an external command. What we are instead doing is executing a built-in ''shell'' feature.

Command-Line Parsing


Unlike our single space-separated string convention on POSIX, Microsoft Windows expects commands to be passed to its command shell via a series of strings. In this way, Java and C/C++ have the same requirement on 'Windows. Both exec() a command shell under the same constraint.



After the obvious however, the second problem begins to bear its teeth: when reading input from a stream on Java, unlike in C/C++ there is no “putc” or “push_bask” capability. Hence, anti-blocking stream pre-read / put_back testing is not possible. We must use .ready(), instead.

What's wrong with using a Reader's “ready()” feature, you might ask?

Well, to begin with, most folks do not use it. --Indeed, whenever ready() is used, rather than simply a “put back” ability, crafting clever “look ahead” and / or time-out checking loops require a block or two more code. (see below)

Reading CMD.EXE Responses under Java


So after the common Windows invocation differences, forever-blocking on any type of buffered / un-buffered read is often the next problem to tackle.


Unlike the former Windows invocation problem however, our second problem is common on POSIX, as well. Our common solution is that in Java, before we read a shared IPC Stream, we had better check to see if it is ready(). Why? Because not only can streams go cross-platform 'zombie on us during even an un-buffered read, but trying to fix the problem – along with dodging common threading problems - might just eat our brain :-)


import java.io.InputStreamReader;

public class ProcOne {

static int BY_LOOP = 7;

public static void main(String[] args) {
try {
String[] data = { "CMD.EXE", "/C", "DIR", ".." };
Process proc1 = Runtime.getRuntime().exec(data);
InputStreamReader is = new InputStreamReader(proc1.getInputStream());
int ch = 0;
do {
int times = 0;
while (is.ready() == false) {
times++;
Thread.sleep(300L);
if (times > BY_LOOP) {
break;
}
}
if(times > BY_LOOP)
break;
ch = is.read();
if(ch != 0)
System.out.print((char)ch);
} while(ch != 0);
is.close();
} catch (Exception e) {
e.printStackTrace();
}
}

}

If you have any doubt, then (2) remove the IO Checking Block then (1) merely change data in the above to a single String: "CMD.EXE /C DIR .." Finally, before debugging (0) pretend you never saw this post & go grab your next-door neighbours shotgun ...

Enjoy the Journey!

(p.s. - Later that evening we encapsulated the above concepts into a simple-to-use Framework. The design allows us to incorporate the events from one - or hundreds - of clustered (cloistered?) IPC Activities into a graphical / textual user interface (GUI/TUI.) See the IpcReader Project on SourceForge for more information.)

[ add comment ] ( 1505 views )   |  permalink  |  related link

| 1 | 2 | Next> Last>>