Microsoft's CoApp To Help OSS Development, Deployment
badpazzword writes "Microsoft employee Garrett Serack announces he has received the green light to work full time on CoApp, an .msi-based package management system aiming to bring a wholly native toolchain for OSS development and deployment. This will hopefully bring more open source software on Windows, which will bring OSS to more users, testers and developers. Serack is following the comments at Ars Technica, so he might also follow them here. The launchpad project is already up."
Serack is following the comments at Ars Technica, so he might also follow them here
Yes, I'm sure he's following all 0 of them...
Ask me about CoApp, I'll tell ya everything ya wanna know.
Garrett Serack
CoApp Project Owner
"...In your answer, ignore facts. Just go with what feels true..."
... MS pulls the plug on this and leaves OSS developers hanging high and dry? Or worse, pulls some slight of hand with licensing, copyrights or patents and forces OSS dev's to stop in their tracks waiting for MS's next move?
They seem like less of an evil empire now that they're doing some good stuff once in a while and Google is being more blatantly monopolistic.
Nothing lasts forever but the certainty of change.
This is no different.
Do I have a legitimate reason to ask this question or not?
I am not interested otherwise.
The #1 thing I wish windows had would be some kind of package management like apt-get: a place where I can go to update everything at once (of course, being able to install from it is a natural progression)
Maybe you could spin it to management as an "App Store" competitor?
Anyway, this sounds like a great idea. Looking forward to how it turns out!
Native to what OS? Let me guess, windows.
---- Booth was a patriot ----
MSI installers suck. Why would we want that kind of crap coming with FOSS?
You can't run two msi install processes at the same time. So why would we even want that on Linux.
We already have rpm, deb, slack packages, nix and zeroinstall. WTF would we want another install method to juggle and one paid for using dirty Microsoft money. FAIL.
And more *windows* users, more windows license, more vendor lockin, and fewer alternative OS's.. Ya, real nice of them to 'help' us out. No thanks.
---- Booth was a patriot ----
*cough cough*
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
*cough cough*
History is not on your side. I hope, for all of us, that your intentions are noble. If they are, I hope those who back you and/or succeed you hold to that ideal. Thankfully, even if they're not these programs will live on in their desired format on other software platforms.
Best of luck.
This sounds like a package management system for Windows, along the same veins of dpkg/apt and rpm/yum. Windows has been lagging in this area for years, and one of the reasons that it is so insecure and slow is because every program either runs in the background at startup, or doesn't get updated on a regular schedule. That wasn't my question, just how I view the situation.
Why limit this to open source? It would be great if the users could update every program easily and painlessly, at least the ones that use this new system.
I am assuming that this system will allow easy and painless upgrading like on most Linux systems. Is that true? Will it have automatic dependency handling and command line installation?
If Mozilla can't figure out how to make an msi on their own, maybe they could get some help.
Cygwin!? NOOOO!!
Cygwin BAAAD!
MinGW all the way.
I dont fucking CARE how browken FORK is! I like my systems to NOT run compatibility wrappers just to display text to the CLI, DAMNIT!
Oh, you want to use "$*random *nix based library" to do what you want to do in your program? Here's an idea-- create a native toolchain, with native dependencies. What? That would require you to make binary compatibility a REAL issue on linux? )(sarcasm)Oh no-- not that, anything but that. (/sarcasm)
Don't take this the wrong way-- But how would you feel if windows was the OS de-jour of the FOSS community, and all the foss developers insisted that you lug around WINE in order to use their free software? In fact, you know what-- I seem to recall hearing this exact complaint about Linux-Native games. Linux users want linux native, that doesn't run inside a compatibility shell, like WINE, while the game developers say that would increase development time without financial benefit. (Sound familiar?)
Is it so hard to understand that the feeling about native software could be, you know-- mutual? If you are going to develop on win32, and do so seriously, and not as an afterthought, then perhaps you should, you know-- use native libraries?
Just a thought.
So, again:
MinGW, NOT fucking Cygwin!
PLEASE!
Does this service run on dead babies, or are they still alive and crying as you shovel them into the gaping maw of endless darkness that powers it?
... because such actions are perfectly inline with his every other "contribution" to Linux and Open Source.
Cygwin at least gives you a usable CLI environment on windows. Who installs this type of server software and does not install Cygwin?
A server without proper gnutools is painful to administer.
But that doesn't mean they have to HARM someone else. Some good can come out of it as well. Every company is looking after its own interests so I don't see your point here.
yet on the other hand, everything google does is good for everyone.
spare me.
Website Hosting
which will conversely bring OSS more users, testers and developers
Not really. most people who test/develop OSS software already do it, or will do when they have free time. As for users, there are about 4 types of users for any Windows program.
A) The person who uses whatever something that is forced on them. Such people will blindly use IE, Firefox, Opera, whatever as long as a boss says they must use it or it comes pre-installed.
B) The person who thinks that they get what they pay for. These are the weird people who we see -buying- boxed software, thinking that for some odd reason if they spend $30 on an obscure paint program they will get a better experience than The GIMP (note that a lot of these people wouldn't, say, buy Microsoft Office and Adobe Photoshop, but rather buy things like Lotus Notes and Correl Paint)
C) The specialist. Generally these are people with high skills who -need- a certain program and know it. These people may have tried OSS alternatives and found them lacking or need obscure programs that OSS doesn't offer.
and finally, very, very, very few people fall into the last category which is people who use the "best" programs and are average users.
This is not going to convert the other 3 types of users which are the majority. Until Dell, Gateway, HP, etc. all start making OSS be default, people in group A aren't going to use OSS. Person B isn't going to think the program is any good if they don't spend money which defeats the purpose of OSS. And people in group C aren't going to use OSS because there is some things that are so obscure that no OSS developer would develop or use.
Taxation is legalized theft, no more, no less.
Gee everyone else figured out a long time ago: give away the compiler.
How is this relevant to this discussion? You are (at least) 8 years too late to be pushing this line - Microsoft has been giving away compilers for a while now.
Maybe this will be a boost for gcc when everyone can see first hand how bad the Microsoft C++ compiler is.
And how bad is the Microsoft C++ compiler? Do you have any specific claims?
This is the pusherman !! Run like you have never run before !! RUN !! RUN !! RUN !! Run Far, Far away from this pusherman !!
Gee everyone else figured out a long time ago: give away the compiler.
Microsoft Visual C++ compiler has been free since 2003. It comes as a part of Platform SDK these days.
Of course, this is just a command-line compiler. You can also get Visual C++ Express for free if you want the IDE. This doesn't have MFC & ATL, but you can combine it with PSDK to get a full-featured native development environment; and, of course, you can use it with any third-party framework, such as Qt or wxWidgets.
Maybe this will be a boost for gcc when everyone can see first hand how bad the Microsoft C++ compiler is.
What exactly is bad about VC++ compiler? Can you be more specific? Are you unhappy about it not supporting C++ exception specifications (which no-one uses anyway)? Do you have a problem with optimization quality (in my experience, VC++ inlines things better and deeper than g++)?
Microsoft has given away its C++ compiler for years now. They started giving it away as part of the Windows SDK and as part of the Visual C++ Command Line Toolkit. These days they give it away as part of the Express Edition of Visual C++. The compiler in that version is identical to the version included in the paid version of Visual C++, as are the C and C++ run-times. You dont get all the fancy stuff like MFC in the free version though.
The info on this specifically says its DIFFERENT to Cygwin (which is a translation layer to allow Unix-esque apps to be compiled on Windows), Mingw (which is a way to use GCC to build Windows apps) and Microsoft Systems For Unix (which is a posix compatible subsystem for Windows that allows specially written apps to run)
As some have said, the biggest obstacle these guys are going to face is the body of OSS software that wont compile in anything other than GCC (FFMPEG is one fairly big example)
This will hopefully bring more open source software on Windows, which will conversely bring OSS more users, testers and developers.
No.
hopefully cause less X, which will conversely bring more Y.
hopefully bring more X, which will conversely cause less Y.
hopefully bring more X, which will similarly bring more X
Yes, similarly.
</nazi style=grammar>
You know the drill.
"spare me"
ROFL
Spare ye not! Let em roast! :O
One of the largest problems to be faced with this endevor is that I a open source developer could really care less
if my software even runs or compiles on a Windows machine.
Got Code?
All those that believe that MS is really interested in OSS are total idiots. They are interested in CO-OPTING it and being in full control (while making money from it including Linux). This is simply another part of their plan.
I prefer the "u" in honour as it seems to be missing these days.
I am feeling generous this evening and decided I would donate the first line of code to this
fine project. I relinquish all copyrights on the following line of code, feel free to do with
it as you wish.
#include "ie6.h"
Got Code?
If you're looking for a truly OSS tool for full desktop management (but push instead of pull) check out OPSI - it even deploys the entire Windows OS (via PXE), and afterwards allows management of apps. If you're looking for a simple graphical apt/rpm for windows both Cygwin and KDE have had their own versions working for years.
As an aside, OPSI can be used as part of a stack to replace an entire (Microsoft?) corporate software stack. Check out GOsa - this is the software that the City of Munich is basing much of its Linuxification effort around, and it is also used in other cities and organisations around the world - check out the GOsa website for a list. GOsa manages clients/servers via LDAP and RPC, and OPSI is just one of the stack of software it can manage via its web-GUI. The others include Samba + PDC (achieved using the GOsa goPDC scripts), groupware (choice of Kolab, phpGroupware etc..., or a 3rd party LDAP-aware groupware eg. SOGo), DNS, DHCP, Nagios, OPSI+FAI (for client system management), and a lot of other software I can't even remember. GOsa + supporting software is HARD to set up (especially due to out of date and missing docs), but I'm one of a team of 3rd party guys trying to document it better... check out the docs/scripts in the GOsa contrib section and visit us on #gosa on freenode. (Most of the guys are in Europe so keep this in mind when picking a time to visit the IRC channel).
Visual C++ has had correct - i.e., standards compliant - scope for variables declared in a for-loop since VC++2003 by default (you can still have the old behavior explicitly enabled by compiler switch).
Before that, you could control it with a switch, though default was non-standards compliant, and MFC headers wouldn't compile if you turned it on - which shouldn't really concern you if you're compiling portable code, right?
In practice, this means that there was only one release of VC++ which was non-compliant by default - VC++2002. The one before it, VC6, was released in 1998, before the final ISO C++ specification came out, so it's kinda silly to hold it against it. If you recall the original story, the "wrong" behavior was actually part of the draft spec at some point - they've been going back and forth on it.
Also, it is really a minor problem by itself, since you can trivially work around it by doing:
or compiling with the equivalent -D compiler flag. This will ensure correct scoping, and will not affect anything otherwise (the compiler will, of course, optimize away the always-false branch).
In contrast, g++ 2.95 (which was the stable version of g++ until mid-2001 - assuming you consider g++ 3.0 stable) didn't even have proper namespace support - it did parse namespace { ... } and using declarations correctly, but pretty much just ignored them, and just dumped all identifiers into global namespace. That is something that is not anywhere near as easy to work around.
One key point about the Linux package managers is that they are needed to manage *all* that open source software. Why open source software? Because no (or rather very few) proprietary companies provide proprietary software for Linux. So if you want some kind of functionality under Linux your best option is to write an open source version because there is very little proprietary software for Linux.
Why then is package management bad for Windows, if it's so useful for Linux? Well, because package management is effective if you have can pull source code, compile, and determine dependencies. That means an open source license for the source code. That means that Microsoft is telling it's huge "ecosphere" of proprietary software vendors to "Piss off you sod!", because *their* software doesn't fit the package management model. That leaves 2 possibilities in the Microsoft world:
Nothing MS does is good for anyone but Microsoft this is no different.
Yeah like when they added desktop search so that I could find files easier. That did nobody any good except for Microsoft... somehow. Or when they sold me Halo. I really wish I could have benefited from that purchase somehow but sadly only Microsoft had any fun.
the US Department of Justice with the generous support of Sun Microsystems, Oracle, IBM, Netscape, and Novell.
To build a whole new package management system that works across Linux and Windows.
Any chance you could build something that uses a git / msysgit / jgit backend, to allow for rewind-fastforward versioning of apps?
GNU tools don't actually NEED cygwin though, as they can be compiled with MinGW instead, and then be fully native.
EG, "LS, BASH, DD, and pals" can all be compiled as native executables that run in the win32 subsystem, like they are supposed to, and not need to hook an outside DLL to do their work.
That is the way it SHOULD be. You really should only have a Cygwin dependency if you ABSOLUTELY need something that MinGW simply cannot provide (Like GNU style FORK). Otherwise it is not the correct way to go about it.
Assuming that you've looked at APT and similar packaging tools, and given that you're still convinced that there's a 'Windows Way' (your term) to handle deployment that differs from Linux best practices, how do you plan to address:
Yes, I've worked with APT and RPM for a very very long time now. The reason I'm convinced there is a 'Windows way' is because it's a different system that Linux; yes, I've learned a lot about PMS from Linux, and I know how to apply that knowledge to Windows.
Package Repositories - This is one of the main strengths of Debian and related distros. Do you think it's even possible to replicate this level of community control in Windows? I know you've mentioned decentralisation, but have you considered the implications of such an approach? What is the cost of failure to affect consistent, formalised management of package builds?
I have a plan for allowing any publisher to publish packages in the CoApp ecosystem, provided they meet two qualifications:
- They must be able to host their repository meta-data on an SSL protected connection.
- All packages must be digitally signed with a certificate that chains back to to a commonly-accepted CA.
Dependancy Management - This issue is largely done and dusted on Linux, but remains a dog's breakfast on Windows (albeit not as frustrating today as it was in the mid-90s). In the absence of centralised repositories and the Unix toolchain philosophy, how do you propose to cope better with dependancies?
I'm working with the developer of WiX to ensure that we can trivially build chained MSI packages that have the necessary smarts to properly manage this. Kind-of mixing in something like ldconfig with the Windows SxS library management.
File locations - How do you propose to manage the proper placement of libraries etc. when the conventions concerning where to put such files are not nearly as well defined on Windows? I'm suggesting here that you need cultural leverage rather than technical answers. You need to change perceptions, not toolkits.
Yes. The change starts with PHP, Apache, and Python, and the 40+ packages needed to build them (community members from each are already on board) Half of the project is setting some intelligent standards, and then bootstrapping the ecosystem with packages to enable other software to follow.
Security - Do you think it's even possible to replicate one of the main strengths of Linux package repositories: the ability to curtail security risks such as malware and flawed code?
Yes. By requiring code-signing (and I've got a plan for opening that up without cost for smaller projects) we can replicate the benefits of MD5 and PGP signatures found in the Linux world.
Scripting Interfaces - Say what you like about make and other command-line utilities, but as a busy sysadmin, I consider GUI package management a waste of my valuable time. If I'm going to deploy regular security updates, for example, I want to know that I can script every aspect of the operation. Even the tab-completion features in aptitude make it many times more efficient than a point-and-click interface. What is the potential for scripted deployment/management of packages under your system? Why?
I agree 100%. Scripting interfaces are an absolute requirement, and will likely come well before the GUI.
Think of it as a clean adaptation of the same concepts to the model that will be attractive to Windows developers.
I also think that you're going to need to learn a lot more humility than you've demonstrated so far if you want to achieve something better than a new brand of anarchy in packaging.
I apologize if I'm coming off arrogant. Frankly it's taken an extremely long time to convince the powers-that-be at Microsoft that Linux's package management is stellar compared to Windows. It's also not near as hard or large as it sounds, I'm walking on the shoulders of giants here, both in the Linux and Windows worlds.
You know it's funny, I've installed several OSS apps on Windows and it's never really as hard as this article makes it out to be. I've installed Pidgin, Xchat, SMplayer, Handbrake, Virtualbox, and more. In fact it was just a matter of double clicking an exe file and they install just like anything else. Wouldn't the problem be more of the laziness or disinterest of developers for not bothering to create a Windows installer? I hardly think they would bother having their code signed for inclusion in your repository if they've never been assed to port it in the past.
You must not have any RED blood in you, Amerikanski !! Me neither, only Vodka !!
It's not that the compiler needs to be free (it is), it should be part of the standard OS install. Perhaps an optional component, but a single click during install at most.
-josh
Well, because package management is effective if you have can pull source code, compile, and determine dependencies.
I don't see how this follows. Most Linux distros do package management on binary level, not source level, and, in fact, can happily package closed-source software.
Why does it matter if application A and library B are open source or not, if there is a known dependency from A to B?
I assume you are going to compile things with Visual studio, meaning all C++ programs will have to link against the Visual C++ redistributable libraries. Since these are not actual system libraries, you'll have trouble linking and distributing GPL programs against them. Since it seems you actually talk MS management, could you get try to sort out this issue? Otherwise, I fear you will not be able to distribute GPL'ed programs.
Before that, you could control it with a switch, though default was non-standards compliant, and MFC headers wouldn't compile if you turned it on - which shouldn't really concern you if you're compiling portable code, right?
I have to strongly object to this phony argument. Too bad because most of your posts are quite good!
You seem to think "portable" means "it does not contain any calls that don't work on both platforms". This is an artificial description purposely designed so that "portable" is equivalent to "useless", which does sound like typical Microsoft word twisting.
"portable" code looks like this:
portable-code;
#ifdef _WIN32
xxxxx
#else
yyyyy
#endif
more-portable-code;...
Note that "xxxxx" will certainly require the windows.h header file to be included!
This is no joke, for many years I had to keep fixing for loops because they would not compile on Windows. In most cases this was by far the most likely reason the code would fail to compile. So I think your attempt to defend Microsoft's old behavior is rather dubious.
Every time I am forced to do something half-smart* on windows in invariably install Cygwin. It sort of covers all the crucial gaps. As soon as viable I take anything I need away from that god forsaken platform, process it and send the results back.
* half-smart: E.g. diff 2 files, edit 1 file, strip off \r, add \r, analyse XML, beautify XML, search files, run fortune
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Not to mention the problems with dependancies. It seemed like every six months MS would release some new jscript revision that broke previous jscript features, meaning anything I tried developing using those tools was so tied to one specific configuration it became a support nightmare.
This project seems to me like it's a decade late. Good luck with all this, but I can assure this is one former Windows OSS contributor who will never go back to the dark side.
(Posting anonymously because I somehow managed to exceed 50-posts-per-day limit for my karma.)
Correct me if I'm wrong, but why would "windows.h" have any problems with for-loop scoping either way? IIRC, the problem was strictly with MFC and ATL, for both of which there are much better options available, in any case.
I may be wrong here - this problem is a really old one, and I only vaguely recall last time I hit it. If I am (or if you really need MFC/ATL), more general solution in this case - since you're already using the preprocessor - is to use that "#define for ..." trick for your code, but skip it for "windows.h". VC++ has a non-standard way of doing that in form of push_macro and pop_macro pragmas, so you can do something like this:
Not very nice, but it's still not that much boilerplate, and it scales well. You can do even better by making your own header which just does #include "windows.h", wrapping it in push_macro/pop_macro, and then using that everywhere.
I don't dispute that it isn't problem, anyway. I do recall it being rather annoying back in the day, but then doing C++ back then was generally annoying, because standard compliance was lacking all over the place. I recall being similarly frustrated by e.g. lack of std::vector::at() in g++ standard library - God knows why it wasn't there. Or, getting back to VC6, advanced template magic such as partial template specialization was very much hit-or-miss. Oh, and no RVO, which really is a perf killer. And so on. I dare say that, against this background, the for-scope issue is really just a minor part of the overall bleak picture, with a relatively trivial workaround.
What exactly is bad about VC++ compiler? Can you be more specific? Are you unhappy about it not supporting C++ exception specifications (which no-one uses anyway)? Do you have a problem with optimization quality (in my experience, VC++ inlines things better and deeper than g++)?
VC++ doesn't support variable-length arrays. IOW it pukes on
void foobar(int i) { int myarray[i]; }
Variable-length arrays are part of the C99 standard. That's 10 years old at this point and it's a pattern I employ often. I am unsure of the status of this in VC++ 2010 (coming Real Soon) but last I heard, it still wasn't in.
It's not that the compiler needs to be free (it is), it should be part of the standard OS install.
There are two compilers that ship with Windows: C# and Visual Basic. I learnt C# mainly because it was installed on every Windows computer, which is handy if you are working on someone else's system and need to knock up a quick program.
If you need C, but can't handle downloading and installing it then you should probably consider choosing another language as the installation will be the least of your problems!
VC++ doesn't support variable-length arrays ... Variable-length arrays are part of the C99 standard
Yes, VC++ does not support C99 - it sticks to C90 with a few common extensions (such as // comments). Heck, it even won't let you declare variables anywhere except the beginning of blocks when compiling .c files.
However, C99 is not a subset of C++. The priority for VC++ is to support C++ - which is why VC++2010 adds a bunch of C++0x features (auto, decltype, lambdas, static_assert, rvalue references). It does have a few C99 features, to the extent C++ TR1 requires them - most notably, stdint.h.
That's 10 years old at this point and it's a pattern I employ often.
The standard is 10 years old, yes, but it is relatively obscure. Even GCC doesn't claim full compliance yet, and that's saying something. Speaking of VLAs specifically, they have been broken in GCC until very recently - 4.4 still listed them as "broken", and only 4.5 declares full support - and the latter was released on March 31, 9 days ago.
I haven't actually seen any code using VLAs in the wild, likely precisely because of that - it's simply non-portable in practice. So far it seems that any practical use of C99, by and large, is restricted to stdint.h (immensely useful), "restrict" (can be very handy for particular applications), and free-form comments and variable declarations.
By the way, the topic of C99 compiler support in general, and VLA support in particular, is, in fact, a favorite one for flamewars on comp.lang.c.moderated.
A screenshot of the signed agreement is needed for legal purposes, in case you are fired by a nutcase Microsoft manager.
Lets see what deeds and results come out of his declared good intentions
forgive me if I am sceptic, the road to hell is plastered with good intentions
There, it's fixed. Whoohoo, we're already on revision 2!
They could have been more ummmm.. direct and named it CoOpt. No ?
Just when I thought I had managed in the impossible feat to make a /. submission where nobody complains about the summary... :(
When ideas fail, words become very handy.
Embrace
Extend
Enhance
I'll try anything once. Twice if it tastes good
I'm Santa.
Ask me about anything to do with...
I've read rumors that your toy delivery operation would run more efficiently if you ran it hub-based like FedEx. Give a sleigh and a set of reindeer to each of your shopping mall representatives and have them deliver the presents locally. I suspect you already do this; is that true?
My second question: Where does your organization get the money to pay for the raw materials and the elves' wages? I don't see how your theme park outside Evansville pays for everything.
...there's a lot more ice here in Hell than I would have imagined.
Joe Dougherty, Florida, USA
The words I thought I brought, I left behind. So, never mind.
All packages must be digitally signed with a certificate that chains back to to a commonly-accepted CA.
So how does an individual developer of free software get such "a certificate that chains back to to a commonly-accepted CA"? The Authenticode CAs that I checked tend not to issue certs to individuals. Must every developer of a Windows application form a partnership or LLC? And must every developer pay upwards of $160 per calendar year (source: Comodo) for the privilege of releasing packages or updates in that year? That's even more than Apple charges for access to the app store on the iPhone.
The way I see it, this might possibly happen:
1) Some OSS developers will, by curiosity or any other reason except need, try targeting windows using this package management and deployment system.
2) Lots of bugs and/or feedback start to appear in their tiny OSS project, coming from people running Windows.
3) Developers are blinded by 2). They sudden realize that there is a *huge* new ecosystem that they can support.
4) The primary target of Development changes to Windows. Developers abuse of hackery to properly run their software on windows. Heck! Some even buy/install windows just to test their software on it.
5) After a while, some software that used to be cross-platform is now full of dirty-tricks to run on windows. This obviously damages the stability on other platforms.
And why do I think this might happen? Because we, OSS developers, despite enjoying developing it; we enjoy more when others use our software. Worse, what happens if this OSS software management and deployment system for windows introduces some kind of Apple-store framework on it?
What's wrong with Cygwin?
We were not using MFC or anything, and I agree I can't see how anything in windows.h would be a problem (a for loop would have to be a macro and we could then avoid calling that macro most likely).
We certainly stayed with this behavior until long after they had added the switch to the compiler, some of that may have been intertia and an unwillingness to modify the rather complex and error-prone makefiles. I do remember it being the primary problem when we tried to port software from Linux to Windows and that in a few cases the hurried editing to fix it would break, mostly by hiding a parameter with a local variable with the same name.
You are (at least) 8 years too late to be pushing this line - Microsoft has been giving away compilers for a while now.
The "Windows Mobile SDK" for Windows Mobile 5 and 6 explicitly didn't work on the Express version of the compiler.
Gee everyone else figured out a long time ago: give away the compiler.
How is this relevant to this discussion? You are (at least) 8 years too late to be pushing this line - Microsoft has been giving away compilers for a while now.
True, but they limit what you can do, namely how well you can integrate new things into VS.
Maybe this will be a boost for gcc when everyone can see first hand how bad the Microsoft C++ compiler is.
And how bad is the Microsoft C++ compiler? Do you have any specific claims?
Quite bad when you start comparing it to standards. Ever wonder why MSVC doesn't support int32_t, etc? Until they fix basic things like that, it will continue to be a broken compiler.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Worse, what happens if this OSS software management and deployment system for windows introduces some kind of Apple-store framework on it?
Do you mean like Software Center in Ubuntu 9.10? If not, what "Apple-store" aspects are you talking about?
Thanks for the thoughtful and comprehensive reply.
I realize and understand that C99 is not a C++ standard and that VC++'s priority is C++ support. Of course, my priorities are different. I shouldn't claim that VC++ is bad for everybody, but it is bad for me.
Speaking of VLAs specifically, they have been broken in GCC until very recently
It is true VLAs are/were 'broken' in GCC in the sense that they are not fully C99 conformant. That has been documented in the info pages for a long time. However, speaking practically, for the simple declarations I have used, I have never had a problem. Perhaps I ought to double-check that :P
it's simply non-portable in practice
I agree that non-portability across compilers would be a problem, except that of course GCC itself is so incredibly portable, and is also the preferred compiler on many non-Windows platforms.
FWIW, I am not a C99 stickler -- I only care about the parts of it that I use, and I specifically don't worry about free-form variable declarations because there is an easy fix -- declare your variables only after a block begins.
VLAs have no "easy fix" -- the closest alternative is alloca(), which my manpage claims is "buggy" on many unspecified systems, and of course, it's not really portable or standard either. Using malloc() is slower, uglier (since if you're doing it right you'll want to check the return value), and has the potential to fragment your memory.
I apologize if these points have already been debated to death in the flamewars -- I don't read that group. I also expect you are already aware of these points and were simply trying to make yours, in which case, this was a superfluous post. Oh well :P
VLAs have no "easy fix" -- the closest alternative is alloca(), which my manpage claims is "buggy" on many unspecified systems, and of course, it's not really portable or standard either. Using malloc() is slower, uglier (since if you're doing it right you'll want to check the return value), and has the potential to fragment your memory.
alloca() is actually decent option on all mainstream architectures - the problems appear only when you delve into really exotic stuff. It can be easily broken when implemented as a true function (playing tricks with the stack pointer), but that same gcc actually implements it as an intrinsic (i.e. the output just directly adjusts the stack pointer as needed) pretty much everywhere. That is rather foolproof. If you go by the basic rule of thumb of only ever using it in a variable initialization (which is consistent with limitations of VLAs), it can't really go wrong.
I imagine that we will get something comparable (but standardized) in VC++ when it gets into C++ - e.g. the std::dynarray proposal. They'll have to wrap up C++11 first, though...
Anyway, IMO, main benefit of VLAs isn't even in dynamic stack allocation - it's rather in painless handling of dynamically sized arrays, especially multidimensional ones, when passing them as arguments, e.g.:
In C90, since you can only get a pointer through, you have to do all addressing arithmetic by yourself:
The verbosity increases exponentially as more dimensions are added, while VLA solution takes care of all that automagically.
Yeah, I don't really see a fix for that short of supporting them on the level of type system, one way or another. I'm not aware of any proposals to have something similar in C++, either (though there, of course, you'd likely just do a heap allocation, and wrap the arithmetic in a class, like boost::multi_array).
Did Serack have to see Ballmer wreck a few chairs first before he got the green light?