Why does this surprise anyone?

Story: Windows GUI vs. Linux Command Line MythsTotal Replies: 11
Author Content

Nov 09, 2008
2:58 PM EDT
Seriously, why? We know that the Windows GUI is not a programming language, in that it lacks the most basic of constructs, like "do this task, then do that task" (i.e. sequential execution) much less possessing looping constructs or if-then-else. So it just *can't* do the sort of things that a command line interpreter does. Some people still argue about this, nonetheless.

One of the security guys at the Immoral Giant Corporation that employs me noted that the ".NET" people have even less of a clue than the "J2EE folks" once something goes even slightly wrong with the application in question, so I guess I can confirm that "low level interaction with Windows" is indeed a dying art. Unfortunately, he told me this in the context of me moaning about hw the Java "programmers" didn't understand much about basics like Solaris signal handling, unix/linux filesystems being case-sensitive about file names, etc etc.


Nov 10, 2008
4:55 AM EDT
Hmmm, is Windows Powershell any good?


I imagine that even if it were the best cli ever invented, nobody is actually using it for anything.

Nov 10, 2008
5:03 AM EDT
Quoting:Hmmm, is Windows Powershell any good?

Yes-and-no. It works. It's miles ahead of the original Dos/Windows CLI. But Windows sysadmins detest it (no GUI) and it basically runs .Net so it's extremely verbose.

Quoting:I imagine that even if it were the best cli ever invented, nobody is actually using it for anything.

They force you. On Windows Server 2008 there are quite a few things you can't do in the GUI. Also, with apps like Exhange 2008, everytime you click "Okay" to execute some command in the GUI an annoying popup appears telling you what CLI command it is going to run. I don't know if you're able to turn that off, but it's annoying the hell out of most Windows sysadmins.

Nov 10, 2008
5:10 AM EDT
Aunty Microsoft strikes again.

Nov 10, 2008
12:31 PM EDT
Quoting:But Windows sysadmins detest it

Not exchange 2007 admins...because we have to live and die by it. Also, it's now shipping default with windows 7 AND Server 2008.

Nov 10, 2008
3:51 PM EDT
The docs I looked at for "Windows PowerShell" seemed like a typical Microsoft thing: they made a huge "features list", and then implemented each and every feature in the least imaginative way possible, then declared it Perfect and Unbeatable.

Sort of like Windows NT itself back in the late 80s.

And just like Windows NT, they forgot that you can't just slap together a list of "features" and have it all work together. Towards this, I'd give the example that the first few Windows NT had file descriptors and socket descriptors. Great, a uniform "handle" type. But you couldn't mix file and socket descriptors in the moral equivalent of a "select()" call.

Or take NTFS as an example. Dynamically allocated inodes? Check! They call them "file headers" or some such, they're clearly borrowed from VMS ODS-2. They live in the "$MFT" file. At least until NT 4.0, you could only grow $MFT, you couldn't shrink it. So, you deny yourself service by creating a whole pile of small files, and then deleting them all. $MFT could use up all disk space.

Esthetics has always posed a problem to MSFT, and to all big corporations.

Nov 10, 2008
4:03 PM EDT
@phsolide: "Clearly borrowed" in this case means "the former DEC people remembered what they did at their previous jobs".

Nov 10, 2008
5:59 PM EDT
Quoting:Esthetics has always posed a problem to MSFT

"Bill Gates has no taste" --Steve Jobs ("Triumph of the Nerds", IIRC).

Apr 22, 2009
8:33 AM EDT
Whenever a Windows fanboi says "Linux requires that you configure everything from the command line!" you simply reply "Windows still requires that you edit CONFIG.SYS and AUTOEXEC.BAT to get anything done." When they reply that Microsoft fixed that years ago, you can then point out that Linux did too.

Apr 22, 2009
10:36 AM EDT
> When they reply that Microsoft fixed that years ago,

Point them to the config.nt and autoexec.nt files in the C:Windowssystem32 directory, which are still used for backwards compatibility.

Apr 22, 2009
1:10 PM EDT
Hell, if I want to do anything useful in Windows I have to use cmd.exe. But it's blocked. Meaning I have to reside to command.com, which isn't blocked... Really great, Windows security.

So - I don't speak .NET and don't want to (this.that.fromthat.tothose(); all those dots makes me sick), apart from not having privileges to install MSH - I thought I might install Python Portable. Only to find out I couldn't install the w32 ODBC libraries for it because they were compiled with a different compiler or such a thing. It all became quite messy, to compile this for Windows I need mingW I believe. With Linux, I would have solved the issue within minutes - even with security restrictions, bash, chroot and ldd can do miracles. But Windows doesn't have a free development platform by default, or it should be for Visual Studio Express, but I don't want to spend time learning that. Nice example of how a developer (oh, forgot: I'm not; at least no software developer; just hobbyist with BASIC-skills) is 'locked in' to some platform: If you know one or two languages you don't want to learn much more. And apart from ASM for Z80, BASIC for TI83, bash and Python and some too-tiny-to-mention experiments with haskell, LISP, Brainfuck, C++ and OpenGL (on Windows!), what else programming languages would anyone need? Sure, with that tiny bit of knowledge learning Visual Studio and Windows development is useless.

ActivePython didn't work either, since it touches files which are protected by the sysadmin. Now, I don't work in an IT-function, so the boss doesn't want to see me fiddle with MingW or Python of course. Yes, I could have called the IT department to fix this, but I was too lazy apart from being gone next week.

So I settled on AutoIt3 again, the best Windows shell I came across when Python ain't an option. It's freeware, not free software, but it has a BSD-like license; though the source isn't provided. I'm happy with it. It's really ugly as it's designed as a scripting language to make macro's that use the Windows GUI (sounds like a bad idea, huh? Well, it is!) and rather band-aid like, but at least finally it gets the job done about 80-90% of the time. The 10-20% where it doesn't is mainly the results of timing errors. If you start a search and other buttons become gray you can't click them in Microsoft and it doesn't remember you clicked which is a really good way to crash your scripts. Apart from that PTC and their software must be the least cooperative company/software I ever came across; Microsoft is an open heaven compared to it. Meaning you have to reside to hardcoding mouse-pointer coordinates in your scripts. However, my neighbour has a widescreen and I don't... I warned you this was a bad idea, huh?

The same job could have been done using Microsoft publisher, but of course that costs money, something my boss doesn't receive that much anymore (that's why I'm 'out' next week). Apart from that it send your data to /dev/null saves in a format only MS Publisher and some Adobe products speak. Not an option.

So I wish the commandline was necessary to operate Windows, because if it really was, they would have made sure to distribute some working usable environment I guess. Because Windows is all GUI, when you want to do scripting but not .NET, you're almost on your own.

Apr 22, 2009
1:11 PM EDT

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!