> C was designed on UNIX, and was basically made for UNIX. That's a matter of historical record. But to say that on Windows everything is a little "off", doesn't quite do it justice. I understand that the book is aimed at the uninitiated, but to put it that mildly is an understatement of epic proportions.
Yeah, this was the fist sign I wouldn't read to the end, and I was right. The author just says this, and leaves it at that. As if we are to just take his word for it. This is essentially what this argument boils down to:
"He said X, I say X++." No explanation, nothing to backup what he says, nothing other than a to suggest it's a epic understatement.
Let's put this another way: my comment is has more to backup what I say than this article. The author might be right, but he doesn't back it up.
And I don't even understand why he doesn't agree that C is a second-class citizen on Windows. Microsoft would rather have you code stuff in C++ or .Net and MSVC is stuck with the C90 standard (although apparently that is finally improving)
On the bright side, the author's hate for implicit make-rules, and inability to grasp the pedagogic value of showing implicit includes first, and -Wall later made me go and test the following in a "command prompt for VS2013" on windows:
>more hello.c
int main(int argc, char *argv[])
{
puts("Hello world.");
return 0;
}
>cl hello.c
Microsoft (R) C/C++ Optimizing Compiler Version
18.00.31101 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.c
Microsoft (R) Incremental Linker Version 12.00.31101.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hello.exe
hello.obj
>hello
Hello world.
My reading was that the author just didn't know about implicit make rules. Shaw's book apparently suggests using "make" to compile and link a simple C program. The author goes on at some length about not being able to find the Makefile, apparently unaware that no Makefile is necessary.
The "make" command is rarely used without a Makefile, so this is a fairly easy mistake to make.
Not quite sure what is new here. The MSVC compiler has been available for free for close to a decade at least and command line compilation was available ever since I first used it (in the mid 90s)
I wasn't aware of that. I suppose it came with the driver dev kits? I've not really been into windows development, but I thought I'd at least have brushed up it accidentally if one could use the official MSVC compiler to produce shareware and commercial software for free?
Were there any (free) IDEs that took advantage of this? I thought one of the reasons Stevens used DJGPP was that MSVC wasn't available for free? I suppose I could just be that it wasn't freely distributable, which makes it hard to bundle with a book (at a time when people can't just go and download megabytes of data from microsoft.com).
Or maybe MSVC was free, but not the c++ part? See eg:
(It's not my intention to move the goalposts, you say close to a decade, which means 2005 -- it's quite likely that I'm just biased due to my old age...)
I did literally mean a decade for the compiler (so 2005). While it is not a full IDE by any means, VS Express did include the standard VS compiler. You could compile most standard C programs on windows with that. For some time prior to that you could get a compiler with the DDK as well (but I don't remember since when; it has been a long time). Of course express didn't pack some of the libraries that came with VS; you could get most of them via the SDK and DDK however.
In the 90s though, I used the non-free VS for the most part along with some Cygwin until Mingw's appearence in the late 90s.
Yeah, this was the fist sign I wouldn't read to the end, and I was right. The author just says this, and leaves it at that. As if we are to just take his word for it. This is essentially what this argument boils down to:
"He said X, I say X++." No explanation, nothing to backup what he says, nothing other than a to suggest it's a epic understatement.
Let's put this another way: my comment is has more to backup what I say than this article. The author might be right, but he doesn't back it up.