Posted
by
michaelon Sunday April 18, 2004 @09:26AM
from the look-it-in-the-teeth dept.

FortranDragon writes "Microsoft has made the command line toolkit for Visual C++ available for a free download. You can use the toolkit to build applications and redistribute them if you want (though you should read the EULA for the details, as always). This is a nice boon for those that have to deal with cross-platform compatibility, especially since Microsoft has tried to make Visual C++ more conformant to the ISO C++ standard. Go forth and compile your favorite OSS or FS programs today. ;-)"

With MS's latest C++ compiler (and with newer Os's), you need "\r\n" to make a new line. This drove me nuts when I first started doing it. Now, it's not so bad.

That is weird, I do not have this problem. The I/O layer should translate newlines for you. All I ever use in Windows programs (console and GUI) is '\n' and it ouputs "\r\n" as well as reversing it on input. This is in both MinGW [mingw.org] and Visual C++ [microsoft.com]

I'm fairly sure this behavior is required by the C/C++ standard. The key is to open streams in ASCII mode, rather than binary mode. Because C/C++ are designed to be portable, the standard I/O library is required to convert the line endings (but not in binary mode). Unix's binary mode is equal to its ASCII mode (since it uses \n natively).

If the standard I/O library didn't understand line endings, then functions like fgets() could never work, and working with strings (where you expect to be able to match against \n) would be much harder.

Networking is different, since it uses raw I/O, and doesn't pass through stdio's translation layer. Also, you usually want the binary data on the network.:) The Internet mainly uses \r\n as the line ending (although this made sense in the past, why they continue to stick with it in new protocols is beyond me, besides maybe the ability to easily telnet in and type in raw protocol commands by hand).

Note that fseek() with SEEK_CUR will almost always fail in text mode, since the number of bytes read may vary from the current offset in the file due to the conversion. Recording the current offset with ftell() followed by an fseek() with SEEK_SET will clear that right up.

You guys are evil, and I like it. It's perfect justice to hit M$ with a Slashdot trying to download a tool that represents one the greatest advantages of open source and Linux (at least a little): the native compiler.

You may mock! years ago Watcom had a bug in their C compiler that somehow confused the size of a char with the size of an int. This meant I could write a piece of code, apparently to print out a string one character at a time, but instead printed every fourth character instead. I sent them a bug report including some code that would, in the absence of this bug, print the message "fortune coookie". Note, the triple 'o' isn't a spelling error. Think about it!

MS seems to be doing a lot of this lately. It's nowhere near as open as F/OSS solutions, but it's freeing up access to what's possible with Windows far more than previously.

One of the reasons for the success of OSX is the general geek crowd's appreciation of it's *IX background, but without free dev tools that's nothing but another flavour of unix. Add the ability to dive into developing instantly and there's tens of thousands more developers working for the company.

The page seems to indicate that the.net runtime might be installed on your machine if you execute the download; can anyone who has done it confirm this for me? I don't want to have to drive a wooden stake through my CPU.I'm a MCSE, but I would never purposfully allow.net in my house. it activates all my tin foil hat's little buzzers and lights.

While still not free, XP Home can be had for $85 [bananapc.com] in a full version, not just an upgrade. And that cost only exists if you didn't already buy a computer with 2000 or XP on it. Obviously, you either bought a computer with Win98 on it or bought 98 by itself a few years ago.

Your complaint sounds like someone griping that some piece of free software (could even be Linux-based) isn't really free because it requires a 600Mhz processor and 128MB of RAM and your old 133/16MB will require a CPU and RAM upgrade to run it.

The page seems to indicate that the.net runtime might be installed on your machine if you execute the download; can anyone who has done it confirm this for me? I don't want to have to drive a wooden stake through my CPU.I'm a MCSE, but I would never purposfully allow.net in my house. it activates all my tin foil hat's little buzzers and lights.

What the hell? Informative? You're afraid of a program library? Do you not have any clue wthat.net is?

It's users like you that give MCSE's a bad name (and pagan libertarians as well).

just to clarify this Apple's dev tools ARE included, just NOT installed by DEFAULT.

EVERY new machine SHOULD come with a separate developer's CD just as every boxed version of OSX should. The end user just has to apply some elbow grease in a) noticing this, and b) bothering to install it.

Also in the unlikely event that the developer CD is not present or there is an upgrade it is ALWAYS available(even to free online developer members) as a download. Hell even the old classic dev toolset(name escapes me at the moment) has been available free since, what?, 1994/5 or so?

The only commercial environments are things like Codewarrior(Metrowerks), Absoft FORTRAN, RealBASIC, etc. Codewarrior MIGHT be worth it if you are trying to make money as their compilers are proprietary and USUALLY optimize much better than gcc. (I don't think that anyone has done a recent set of benchmarks of Apple's latest improvements of gcc v. current Metrowerks compiler though...)...and now that I'm thinking of it most OSes of recent years, free AND proprietary seem to come with some sort of gcc based plus IDE dev tools any more anyways, e.g. BeOS, *Linux, *BSD, OSX, MacOS 7.5-9.x etc. On top of this didn't M$ used to have pretty decent pricing(surprisingly) for VC++/dev studio only anyways? (It's been a while since I've bothered to check.)

EVERY new machine SHOULD come with a separate developer's CD just as every boxed version of OSX should.

Twenty years ago I would absolutely agree.

Not today.

Only one in one hundred, maybe one in one thousand users would do anything with this CD. (And I am counting the users who make clocks or other decorations out of useless CD's.) Don't increase the cost for everyone so that you can have a CD in the box.

What development tools? What language? What IDE? There are so many to choose from. If the CD doesn't have the right one, then it doesn't do any good anyway. As soon as two (2) of those tools on that CD are out of date, then the CD is perceived to be out of date.

If developer tools are to be free as in lunch, then why not just make them available for download. This is much cheaper than including a CD with every computer.

I remember a certain 12 year old student who couldn't afford MASM and didn't like TASM so he wrote his own macro preprocessor in C. Then the code was fed back to Debug.com and BEHOLD it worked.

Young programmers today don't realize how spoilt they are. Back in the day we all had our copy of the Intel386 assembler document, and a heavily modified version of Abrash's Zen Timer. Have you ever seem a man shuffle assembler instructions by hand to alleviate register contention, or deliberately NOT'ing AX and reversing the following branch to lull the Pentium into correctly predicting the jump, wasting one cycle but saving 4-7 (depending on whether the code following the branch accessed RAM or not, since the prefetch would have been invalidated).

For that matter, do you even remember when we used fancy tricks to either cope with the 64kb code segment limit, or trounce all over it. I hate to say it, but I miss those days, because back then it took more than an optimizing compiler and a few www tutorials for someone to be called a programmer. You actually had to know at least a little bit what was going on under the hood. It wasn't about compilers and libraries and distributed object frameworks, it was about making a limited machine do limitless things.

A fair number of folks get into FOSS because they can't afford the dev tools. Intel releases a free C++ compiler that runs on Windows, but it also runs on Linux so there's a potential switching-over point there. Making their compiler free is a halfhearted attempt to stop this potential customer leak. It's the same reason why the copy protection on their dev tools is historically weak - in the long run they're better off having Visual Studio get pirated by _everyone_ if it keeps them from losing geeks and developers to competitors.

At college, I knew one student in the CS department who owned a legal copy of Visual Studio, and it had been purchased for him by a contract employer. All the other Windows kids pirated it; the only folks who used Dev-C++ and the like were primarily Linux and MacOS people.

Well I think Microsoft has found out what the biggest threat to their business. It isn't the quality, security or price of their software that makes them popular. It is and always has been how much software is available for their platform. Since the DOS days up to Win 95 or 98 (I am not sure which) Microsoft always packaged some development software with their OS. Although it was usually just BASIC but still it got people programming for them. After they got their market share they stopped giving away their development software, Then hobby developers who often turn professional developers start switching to Linux and OS X because there are development tools out there for them to program. Now over a long period of time as the old windows software companies merge go out of business, consoled or got bought out, there are less software titles available for windows. And the new programmers out there are programming in Linux and OS X get use to programming in that environment and when they make a professional grade application they release it for that platform. So after a while the software titles available to Linux and OS X could match or exceed that of Windows thus Microsoft will then need to find a way to make up the the long period of time of developers.

One could alomst say that it was developers that drive the sucuess of a operating saystem. Without developers, Linux woulden be anwhere. It's time thank all the Linux and *BSD developers, and GNU developers and other Open-Source developers. We need more Developers! Developers! Developers!

I develop software for Windows using MinGW and MSys. They provide everything I need for development, apart from the IDE, and this release from Microsoft doesn't include that.
The Visual C++ compiler is good, but it isn't extrordinary. Why use it over the open source MinGW tools?

I get the impression that when you move above vanilla C code (eg C++, libraries distributed in binary form only), different compilers don't play so nicely. (Just like gcc 2.9x versus gcc 3.x). And most of the binary only stuff out there on Windows is compiled with Visual C++.

I was going to ask about "why get this if there's MinGW [mingw.org]" but I see it's already been asked. I suspected someone would say Microsoft's compiler produces better code. Now where's the evidence? I'm looking for something like independent benchmarks or studying of generated code.

Note that this is comparing MSVC 6 (current version is 7.1, and it's improved a lot). In this test, Intel beats everyone, MSVC comes in second with MingW third, however, both the Intel and MS compilers have improved massively in the last couple years. I don't know about MingW. At least part of MingW's success is that they use MS's runtime library, which means that a great deal of the code being run was compiled by MSVC.

heh - benchmarking, gotta love it. Here's a clue about (more recent) compilers - note that the bench you linked to has what would be a 5-gen-old gcc (2.7.x). even 2.9* used to spank MS' cl 13.x (that's the pre-release versions of 7.0 that were also freely downloadable - in fact, MS used to give away compiler toolchains for a long time as part of the SDK, old news, huh?).

recent icc (7.x, 8) spank about everyone on vector fp due to various reasons (like Intel not releasing a full spec of the SSE2 unit - check out the gcc mailing lists about SSE2, you'll see they didn't have info on timings and so on, hence gcc does only some integer optimization and mostly scalar fp).

icc does some (nice when not useless) automatic parallelization of code (the idea being to use hyperthreading better).

gcc 2.9x -> 3.1+ was a big improvement as well (moreso for 3.2+, check the docs for the new way they do the machine description for scheduling). Just check your own link.

-ffast-math on gcc only has it do what both Intel and MS are already doing - using the bloody fp unit instead of software emulation!!! (easy proof - do an asm dump of the generated.o file).

another big thing that's done by default by icc and cl is the gcc flag -fomit-frame-pointer (which on x86 is quite important due to register starvation). Again, gcc has that missing.

Actually, looking at the compiler flags makes me wonder whether there's any point in taking those bench's seriously - the guy didn't even bother to use anything more than -mcpu=i686 (aka 'generate for pentium pro) for gcc, and the other compilers' switches are still close to minimal (even if they mean quite more than the gcc one). Makes one wonder about how competent the guy doing the benchmark was.

This has nothing to do with hyperthreading. Hyperthreading deals with parallelism between threads, not parallelism within threads. Intel has a seperate facility for the compiler to generate seperate program threads (OpenMP), but the auto-vectorizer does not. The auto-vectorizer works at a much lower level, replacing several scaler ops with a smaller number of vector ops. GCC does not have the analysis technology necessary to do that.

Look at the disassembly for any reasonably complex algorithm, and spot all the platform-specific optimisations that VC++ (and indeed most other commercial compilers on Windows) perform that GCC (due to its portability requirements) does not.

Use Google, and look for people who've compared the real world performance of non-trivial apps built with each compiler. (You might do better with Google Groups than the Google web search engine on this one.)

I have quite successfully linked C++ libraries compiled with GCC, VC++, and the IntelCC compiler with no problems. It appears to be ok. Perhaps code that relies on internals of STL would fail, but at least pointers to STL objects actually port back and forth.

I agree that VC++ produces faster code than GCC. Don't really know how much, because we don't use GCC on Windows anymore because of this, except to make dependencies for the makefiles. Can't be too much today, as our GCC-compiled Linux versions seem to run at the same speed as the IntelCC compiled Windows version.

The IntelCC compiler produces code almost twice as fast as VC++6. I believe VC++7 is much better, however, but have not tested it.

The "learning edition" of MSVC++ prohibited you from commercially distributing binaries made with it (or perhaps even just distributing the binaries, I can't remember just now). It also displayed a pop-up window whenever you executed your code, reminding you of this.

However, considering it cost virtually nothing to get the thing, I don't think this was particularly unfair.

I personally have no love for MS, but I can't help seeing this as a good thing for people that have to support the legacy windows platform.

I recently did some reasearch in AI, and one of the things I did was port an existing simulation written by a former student at my university from a VB/MS Powerpoint front end with BC++ core, to an OpenGL/wxWindows (now wxWidgets) frontend with ISO C++ core.

To establish a baseline I had to make comparisons on the Win32 platfrom. What really amazed me was the difference in efficiency and memory footprint between the VC++.NET 2003 compiler and gcc 3.3.

Although gcc is an excellent compiler, I don't think anyone can argue that MS has the inside track on optimizing Win32 apps.

Microsoft has spent over a decade essentially supporting only ONE processor architecture, x86. The GNU project has to worry about applying optimization to a plethora of architectures, including the quirks associated with each particular implementation.

Not Microsoft - it gets to focus on how to produce the most amount of work out of a processor of at least 80486 grade instructions. How easy is that? They get to throw a hundred developers to extract every bit of performance possible out of one processor. Every now and then make a modification to support a new supplemental instruction set (MMX, 3dnow!, SSE, etc.)

If you read their optimization whitepapers, you will notice that much of their optimization is done at the math level - nothing Win32 specific. Also, their memory optimization, loop unrolling, inlining, etc. is considered top notch by many software developers.

The platform SDK which includes the command line compiler, linker and debugger has allways been a free download (hasn't it). Also, the.net SDK which includes all the languages, libraries, and compilers has also allways been a free download, this is what sharp develop uses.

The command line C++ compiler was never included in the SDK. The C# compiler and so on were, however.

That's incorrect. The.NET SDK has always included the C++ compiler (installed by default to C:\Program Files\Microsoft Visual Studio.NET 200x\Vc7), but the compiler was the Standard Edition, without an optimizer. If you pass it an optimization switch, the Standard Edition issues a warning to the effect that "The Standard Edition of Microsoft Visual C++ does not include an optimizer.". Naturally, lack of an optimizer makes the Standard Edition almost useless for production code.

This newly released command-line compiler includes a fully functional optimizer. It's the same C++ compiler that underlies VC++.NET 2003 Professional.

Clippy: "It looks like you are trying to compile the gimp, did you know the GPL was written by Carl Marx, you don't want to be un-American do you? If you need help embracing capitalism, please ask me."

I know knowledgable comments are looked down on at Slashdot, but the.NET SDK has been free from the start and included cl.exe, (the C++ compiler) but it was the non-optimizing compiler I think. What the.NET SDK didn't have was the full STL and a few other things that are now free.

The end-result of this is everyone gets a free compiler upgrade if they haven't moved to VC7.1 already. It means on my OSS project I can say "VC7.1 minimum," and expect everyone can follow suit without a problem. However I realize this isn't as fun as tin-foil explanations, so I'll let you get back to that.

Only on Slashdot does Microsoft giving away a free command-line compiler (which they've always done in the past along with the rest of the SDK) somehow mean "MS is worried they're losing their development community."

Losing it to what? Windows is 95+ of the market out there. As pointed out before, this isn't some "aggressive effort to get people to start developing.NET apps"--.NET has been a free download since the very beginning.

Did Microsoft have a change of heart? Probably not, this is probably either a part of the anti-trust case against them in which they promised to make their software more interoperable, or it is to stave off anti-trust case part 2.

In general, no. You may use the Toolkit to build C++ -based applications, and you may redistribute those applications. Please read the End User License Agreement (EULA), included with the Toolkit, for complete details.

From the EULA.... Oh wait, I'd have to waste half an hour downloading the compiler to read it. I'm sure there's an evil clause in there. Best thing I could find relating to VS.net runtimes was this old gem:

You may not disclose the results of any benchmark test of the.NET Framework component of the OS Components to any third party without MicrosoftÃÂ's prior written approval.

Do I still want to write non-portable code in 2004? Apparently MSVC produces better code then gcc on Windows, but is that reason enough to use it rather than (e.g.) cygwin?

As a programmer, I insist on platforms that are 100% portable, so that my code can survive any OS and vendor changes. At the very least a commercial compiler must implement the standard language and libraries so that my code is portable.

The Mono group (http://www.go-mono.com) has been working on achieving platform independence with.NET and C#. Programming in C#, in many respects, has the feel that C++ is just getting ancient. C# constructs and methods, although not entirely mature, have learned from the best object oriented languages that we have right now.

C# code for Microsoft's compiler (of an ECMA standard programming language), should run as advertised on a Mono CLR environment - once it becomes mature. Look at the many cross-platform (Windows/Linux) classes available for both.NET and Mono.

Since Mono is an open-source effort, Mono could be extended to MacOS X, FreeBSD, etc.

...I've been using MS VC and eVC to build code under Winblows and Wince for a long time. I use GNU make under Cygwin with a bunch of fancy default rules.

Having this compiler released means thata) I don't have to install that confusing GUIb) I don't have to cough up the money to upgrade (Currently running VC 5.0)..the MS compiler is actually not that bad, and you're stuck with at least *SOME* MS tools if you want interoperatibility with other MS tools. MIDL interfaces (formerly ODL), for one.

I write library code under UNIX in C, debug it in a sane environment (100% GNU, except for Xemacs) and then port it to Windows (generally pretty trivial -- I port by making Windows look like POSIX, so the UNIX codebase stays basically virgin). Run it through MIDL to get a type library, and all of a sudden your stupid VB developers developing one-off, simple GUIs have access to all kinds of well-debugged code that was originally developed on a sane platform.

As long as your code only touches files or sockets, it will run okay under MS VC.

The reports are that this compiler produces better code than GCC (only for x86, of course). How hard would it be to use something like Wine to run it under Linux to compile Linux applications? Would that be a violation of the license?

Then we just need a version of Autoconf that builds a makefile for the compiler of your choice (gcc, icc, or mscc).

Considering a very common (and powerful) optimization of inlining. What you literally do is change function invocations to the code for that function.

Another common (but more advanced optimization) involves making an optimized duplicate of a particular code path.

What you're probably seeing is a difference between the included optimizations in GCC's -O2 verses MSVCP's -02. Try enabling individual optimizations and then comparing code size if that's what you're interested in. That's a more fair metric.

How about making Anjuta (or other FOSS C/C++ IDE's, like KDevelop?) run on Windows on top of this compiler and provide Windows programmers with a free competition to VC++?

This way - they get to learn to use an IDE which they can also use on Linux, MS's income might get hurt because people don't HAVE to by VC++ to develop for Windows with MS's optimizing compiler (which is excellent, you can't say it isn't).

Just take this as an advantage for the FOSS community and do something with it, instead of just bitching all day.

Early on, Microsoft understood that the platform battle is won by those that win the hearts and minds of developers. DOS was a *terrible* environment, but developers built some cool applicaitons and the platform became a huge success. You have to look at this announcement in conjunciton with the Unix Services for Windows announcement.

VB and the VB tools captured a good chunk of corporate developers. I hate VB, but you coul design and build simple forms based applications that talk to a database pretty quickly and easily. Visual Studio provide an excellent intregrated IDE (no flames from Borland lovers) for many C++ developers. it simplified a lot of routine stuff, made finding funcitons easy, integrated the debugger and more. Lots of folks.

IBM recognized that it needs developers for Java to succeed and the purchase of Rational was aimed at getting the corporate developer that is on VB and VC++.

With this compiler and the USFW annoucement, you can now take the *nix stuff and port it pretty easily and for free to Windows. No more need to assemble tools, install Cygwin or the like. There used to be a barrier to getting *nix stuff to Windows. it is now gone. Microsoft will now have a platform, that is free, to allow free software developers to make their stuff available on Windows as native applications. And you cna then add Windows extensions if you want.

The unreliguous among us will grab this and move *nix stuff we've been missing or haven't had access to.

The objective of this is not too hard to discern - keep the geeks and individual developers on the Windows platform. It runs in the same vein as their licensing and releasing Services for UNIX [microsoft.com] - essentially an admission that CMD.EXE is not everyone's cup of tea as a command interpreter and that, to be frank, for proper scripting, it's actually pretty shit.

I'm not quite sure where they'll go next. They may be following Apple's lead, who have, with Mac OS X, managed to capture an extremely sizeable proportion of the more moneyed developer market by taking advantage of the UNIX foundation and integrating it nicely. It may be that the next thing we'll see is a freebie X11 client.

These kind of things start to make Windows an interesting platform - a closed and, possibly, insecure and buggy base but with some interesting and certainly useful FOSS bolt-ons to make it an extremely compatible platform - imagine having both the traditional Win32 and FOSS software libraries available with little to no portage required! It's a perfect situation for Microsoft - keep the users on Windows (DRMed up and whatever), but appease those who are tempted to switch to Linux by building the best bits right into their current platform.

Rumor (and MSDN) says that Longhorn will ship with a full.NET development environment including compiler, debugger, and build manager. This makes it the first time since QBasic that a kid could learn how to program with only the tools installed with the OS. I don't see them integrating X11 any time soon, since it doesn't have most of the features of the Avalon framework that they're trying to introduce. If they did, it'd probably be a heavily extended version.

I wonder if it is possible to use the newer commandline compiler from within Visual Studio 6. From what I hear, the.NET IDE isn't so great for C/C++ work. And come on, a project file is now called a "solution" file?? That's just dumb.

On the other hand, I would really like to have the better standards compliance of the newer compiler.

The Intel compiler can be used as a drop in replacement for the VC6 compiler, so maybe it's possible to drop in this one somehow. Anyone tried this? Maybe it's as easy as just putting the new compiler tools first in the VC6 bin/include/lib paths.

I wonder if it is possible to use the newer commandline compiler from within Visual Studio 6. From what I hear, the.NET IDE isn't so great for C/C++ work. And come on, a project file is now called a "solution" file?? That's just dumb.

I'm currently writing C++ code using Visual Studio.NET, and I haven't noticed any problems compared to Visual C++ 6. Some of the keyboard shortcut defaults are different, but you can revert to the VC++ 6 layout easily.

I think the main reason it might not seem as good for C++ work is that VS.NET adds considerably more features geared towards.NET development, while C++ appears to be neglected somewhat. Remember that VS.NET's IDE supports all their.NET languages, and C++.

For clarification, a solution can contain multiple projects. The old term they used was workspace. Yeah, I thought it was weird at first, but it's just terminology, plus a workspace sort of implies open windows and developer-specific settings to me. A single solution can be used by multiple developers (CVS works nicely).

So as you see most of the differences are new switches for the VC.7 version of cl.exe. Those shouldn't cause any trouble, as VC6 just won't use them by default. The two options removed I don't think are very interesting to most poeple. Besides, the VC.7 cl.exe is happy to ignore them:

What's the problem? The problem is that they've taken a perfectly good word and used it to describe something that it is not. Yes it's just terminology, but all I'm saying is it's a stupid name, and there was no reason not to continue calling it a "workspace". At least "workspace" was a made up word to which they are free to assign whatever meaning they wish, since they made it up.

I guess the thing that really irks me about the name "solution" is that it almost makes sense. It's so close to making sense that I want to interpret it literally, like the code I need written is the problem and the solution is contained in a "solution" file. But the "solution" file doesn't contain the solution to my problem most of the time. Like for instance when my code doesn't even compile yet. That's hardly a solution. Or maybe I should interpret it as the solution to the problem of building my application. The build configuration problem. But the most difficult bits of the build problem are contained in the project files. The "solution" file is just a glorified list pointing to several projects. So it doesn't really make sense to think of it as the solution to the build problem.

And I can't think of any other context in which it could be the solution. So it just bugs me, ok.

I think we need to think of a new interpretation of the.sln suffix. From this day on, I declare that it's is no longer a "solution" file -- instead.sln will stand for a "sirloin" file. Yes, that's it. It's the file that contains the meat that makes up your application. The sirloin file. That's what it is. Ok, now I'm happy. Maybe I'll even upgrade to VC7 now that I can use these cool new sirloin files.

3.2 If you use the Redistributables, then in addition to your compliance with the applicable distribution requirements described for the Redistributables, the following also applies. Your license rights to the Redistributables are conditioned upon your not (a) creating derivative works of the Redistributables in any manner that would cause the Redistributables in whole or in part to become subject to any of the terms of an Excluded License; and (b) distributing the Redistributables (or derivative works thereof) in any manner that would cause the Redistributables to become subject to any of the terms of an Excluded License. An "Excluded License" is any license which requires as a condition of use, modification and/or distribution of software subject to the Excluded License, that such software or other software combined and/or distributed with such software (x) be disclosed or distributed in source code form; (y) be licensed for the purpose of making derivative works; or (z) be redistributable at no charge.

****
Does "Excluded License" mean GPL? A type of license that requires you to include the source code?
If this is correct, you can't use it to compile most OS programs...
You're also aware that you may not use the complier to produce anything for non-windows platforms... but that yould be difficult anymway.

I ran into this with VS.net 7.1. Upon discussion with the legal types, we determined this:

In order to release our application under the GPL, we would have to write a "special exception" permitting linking with Microsoft runtime libraries, same as we currently do with linking against OpenSSL and some other BSD-licensed stuff.

Not too difficult, but it does tend to become annoying to write all those special execptions. I proposed a minor change to the GPL's wording to address this type of situation, but who knows if it'll make it into GPL 3.

Though there would be no problem compiling existing apps with this toolkit, as long as you didn't distribute the resulting binaries.

This post is not legal advice. Check with your attorney first before doing anything. The issues raised here are quite complex legal issues and you are going to need a damn good lawyer, especially since you're dealing with Microsoft here.

It looks like some GNU developer has already disassembled it and integrated some of the code into GCC.

I just went to compile vi, and an ASCII paper clip popped up onto my terminal:
"It looks like you're trying to compile EMACS. Would you like me to launch the EMACS wizard now. Because you are stupid, I will launch it anyway"

i'm personally having a bit of trouble understanding section 3 of the EULA.

section 3.1 requires that software made with this compiler be distributed under (and i quote) "pursuant to an end user license agreement (which may be "break-the-seal", "click-wrap" or signed), with terms no less protective than those contained in this EULA" (emphasis mine)

section 3.2 is less clear. part (b) requires that the "Redistributables" (which, by that, I assume means the standard library and the API libraries) must not be distributed "in any manner that would cause the Redistributables to become subject to any of the terms of an Excluded License." it then defines "Excluded License" with a description that sounds suspiciously like the GPL and related licenses. (i.e., no Open Source licensing.)

section 3.1(ii) is an odd requirement: "(ii) that the Redistributables only operate in conjunction with Microsoft Windows platforms;" it sounds to me that it is explicitly excluding ReactOS and Winelib. (please correct me. i want to be wrong here.)

under those restrictions, doesn't this unduly limit us as programmers? shouldn't we be the ones who decide how our software is distributed? Microsoft is requiring us to guard our code as closely as they guard theirs. isn't this a bit extreme?

I don't have VC++ installed, so I'm afraid I cannot cite very specific examples. Most of my troubles came from pointers (big surprise there), and if I recall correctly calloc() would randomly fail to initialize allocated memory. I also recall being angry that I cannot sizeof() a row vector in a 2D array, but sizeof() on a 1D array works fine.

Most of my trouble likely came from being a n00b to the language, and coming from a Pascal background I don't quite like the way C does a few things things (like mul

Functions in named classes inside template classes, that are not written inline.

Example: You create a storage class (my example was a self-redistributing binary tree). The template class Storage<T> has a subclass Storage<T>::Element that holds three Element pointers (parent, left child, right child) and one const <T> pointer.

Of course, the Element class has a constructor, a destructor, a copy constructor, and an assignment operator defined. (Copy constructor and assignment op may not be formally required, but my experience says it's a very good idea to define them in anything that holds pointers).

This code will produce an error. VC++ does not handle functions in named classes inside templates that are not declared inline.

(I may have missed some syntactic detail - It's been a long time since I wrote C++; I write C# these days. But the above annoyed me to no end. It works fine with gcc, which on the other hand can't handle when the functions are implemented inline, which should also work):-(

Side note: I absolutely love Microsoft's dev tools. This particular example is the exception to me, not the rule.

CC was the most liberal of them all, it would complile and run your email.

This highlights once again how Windows is a more flexible and modern development platform than Un*x. With Windows, email can be run automatically and remotely, without the need for a separate compilation step.

That toolkit is part of the (also free) Platform SDK [microsoft.com], but you can install it separately. It includes NTSD (command-line debugger) and WinDBG (GUI debugger), and KD (the kernel debugger). NTSD and WinDBG sit on top of the same user-mode debugging engine, "dbgeng.dll". They both include really fantastic on-line help which can teach you a lot about debugging in Windows. That said, they are not for the faint-of-heart (the Visual Studio debugger is much more user-friendly). KD.exe uses the kernel-mode debugger built into every NT kernel by default. Of course, you need a second machine to use KD and a serial cable; when broken into the NT kernel debugger, the debuggee is not in control.

(Incidentally, is there a kernel-mode debugger available for Linux? Last time I checked, Linus opposed the concept very strongly, and Linux did not have one available. He called it a "crutch." Sorry, Linus. Kernel-mode device driver writers *like* their debuggers. I have to say that this could be one of several factors impeding device driver development on Linux.)

If you bothered to download the.NET Framework SDK (even back to Version 1.0) it included a fully functional compiler that allowed you to compile C# applications under the CLR. I believe "cl.exe" was also included, the optimizing C/C++ compiler, with the SDK.

Giving the compiler away for free MAKES sense. The only free, mature Windows compiler available is GNU's C/C++ compiler. Although I prefer open-source tools for development, I cannot dismiss Microsoft's compiler as being one of of the best optimizing compilers _there is_. Its only major caveat is the fact that it is designed for one platform only - Windows.

The for scoping you refer to was introduced in the C++ standard, which VC++ supported as far back as version 5 IIRC, however it supported it in a way that was not very useful. You had to turn off all MS extensions to use it, and that also had the side effect of breaking many other things.

As of VC++7 they have a specific switch to enable/disable the for scoping (current version is 7.1, with 8.0 due out next year).

I haven't used MS VC++ for a few years (fortunately), but does it still get the scope of loop variables wrong?

This is the most annoying thing about using compilers that came out before the final C++ standard. The proper scope of such variables flip-flopped between draft standards. Here's a trick I saw somewhere that fixes this problem.

At the top of your code, put this:

#define for if(false);else for

That will make the for loop variable scope correct, no matter which draft of the standard the compiler follows.

IMPORTANT-READ CAREFULLY: This End-User License Agreement ("EULA") is a legal agreement between you (either an individual or a single entity) and Microsoft Corporation ("Microsoft") for the Microsoft software that accompanies this EULA, which includes computer software and may include associated media, printed materials including best practices, white papers, templates, "online" or electronic documentation, and Internet-based services ("Software"). An amendment or addendum to this EULA may accompany the Software. YOU AGREE TO BE BOUND BY THE TERMS OF THIS EULA BY INSTALLING, COPYING, OR OTHERWISE USING THE SOFTWARE. IF YOU DO NOT AGREE, DO NOT INSTALL, COPY, OR USE THE SOFTWARE.

MICROSOFT Software LICENSE1. GRANTS OF LICENSE. Microsoft grants you the rights described in this EULA provided that you comply with all terms and conditions of this EULA.1.1 General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the Software (i) for your internal use; (ii) for designing, developing, testing and demonstrating your software product(s); and (iii) for evaluation of the Software.1.2 Documentation. You may make and use an unlimited number of copies of any documentation, provided that such copies shall be used only for personal internal purposes and are not to be republished or distributed (either in hard copy or electronic form) beyond your premises except as otherwise specifically provided herein.2. ADDITIONAL LICENSE RIGHTS -- REDISTRIBUTABLES. In addition to the rights granted in Section 1, certain portions of the Software, as described in this Section 2, are provided to you with additional license rights. These additional license rights are conditioned upon your compliance with the distribution requirements and license restrictions described in Section 3.2.1 Sample Code. Microsoft grants you the right to use and modify the source code version of those portions of the Software identified as "Samples" in REDIST.TXT or elsewhere in the Software ("Sample Code") for the sole purposes of designing, developing, and testing your software product(s), and to reproduce and distribute the Sample Code along with any modifications thereof, in object and/or source code form. For applicable redistribution requirements for Sample Code, see Section 3.1 below.2.2 Redistributable Code-General. Microsoft grants you a nonexclusive, royalty-free right to reproduce and distribute the object code form of any portion of the Software listed in REDIST.TXT ("Redistributable Code"). For general redistribution requirements for Redistributable Code, see Section 3.1, below.

3. LICENSE RESTRICTIONS -- DISTRIBUTION REQUIREMENTS. If you choose to exercise your rights under Section 2, any redistribution by you is subject to your compliance with the following terms.3.1 If you are authorized and choose to redistribute Sample Code or Redistributable Code (collectively, the "Redistributables") as described in Section 2, you agree: (i) except as otherwise noted in Section 2.1 (Sample Code) to distribute the Redistributables only in object code form and in conjunction with and as a part of a software application product developed by you that adds significant and primary functionality to the Redistributables ("Licensee Software"); (ii) that the Redistributables only operate in conjunction with Microsoft Windows platforms; (iii) to distribute the Licensee Software containing the Redistributables pursuant to an end user license agreement (which may be "break-the-seal", "click-wrap" or signed), with terms no less protective than those contained in this EULA; (iv) not to use Microsoft's name, logo, or trademarks to market the Licensee Software; (v) to display your own valid copyright notice which shall be sufficient to protect Microsoft's copyright in the Software; (vi) not to remov

1.1 General License Grant. Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the Software (i) for your internal use; (ii) for designing, developing, testing and demonstrating your software product(s); and (iii) for evaluation of the Software.

As in, for demonstration only. If you're going to distribute binaries, don't compile them with this tool.

Nope. That clause governs copying of the Software- in other words, the compiler. It says nothing about distribution of works you create using the Software.