Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Who should get the Windows compiler?

By ameoba in Technology
Mon Dec 18, 2000 at 11:12:43 AM EST
Tags: Round Table (all tags)
Round Table

Assuming that the DOJ case against Microsoft goes through and MS is broken up, who should be responsible for writing the compiler? I'm sure the DOJ has plans on this, but from a 'social good' perspective, who'd do a better job, the Apps company, or the OS branch?


It will be some time before the DOJ case goes through, and we know if MS remains a whole, or is split into two. However, if one assumes that the split does take place, who would better handle the Visual Studio line of compilers?

My personal opinion is that by having the OS group responsible for the compiler would be better, because:
  • It would result in a better compiler, more effectively integrated into the OS.
  • If they didn't control the compiler, the OS group would either have to rely on an outside source for the compiler (thereby giving some control over the OS to whomever writes the compiler), or have to internally maintain a copy.
  • Using other OSes as examples, Solaris, Irix, AIX, etc, all have a standard compiler written by the same company (what about MacOS?)

Of course, there are several reasonable arguments against control by the OS group, as well:
  • Having the OS group write the compiler would reduce competition in the Compiler market
  • Forcing the OS group to use an outside compiler would reduce (or eliminate) the oh-so-evil undocumented bits of the API

What's your take on this? Does .NET play into this at all? What would be best for the industry as a whole? The end user? From a technical perspective? Moral? Other?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Visual Studio should...
o be controled by the OS group. 10%
o be controled by the Apps group. 10%
o be controled by a unified Microsoft. 10%
o replace VB with Perl/Intercal/Python/Lisp. 10%
o be ported to Linux. 6%
o be burned at the stake. 29%
o do a little dance;<br> make a little love... 14%
o Inoshiro 7%

Votes: 177
Results | Other Polls

Related Links
o Also by ameoba


Display: Sort:
Who should get the Windows compiler? | 56 comments (42 topical, 14 editorial, 0 hidden)
IMO (1.76 / 13) (#2)
by boxed on Sun Dec 17, 2000 at 08:57:14 AM EST

I personally don't believe the apps part of ms is qualified to work on the compiler.

Qualified? (2.50 / 2) (#38)
by ucblockhead on Mon Dec 18, 2000 at 01:19:41 PM EST

That depends on what you mean by "qualified". It has been my experience that the quality of Microsoft user Apps (Excel, Word, etc.) is usually quite a bit higher than the quality of their systems software.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
OS vs. Apps (3.62 / 8) (#9)
by pb on Sun Dec 17, 2000 at 11:17:05 AM EST

Well, first, it doesn't really matter, because the same people should be writing the same tools, however they do it. That's because development is done in teams inside Microsoft, and the teams will be placed in one department or the other, probably arbitrarily...

The problem with giving either the OS or the Apps people the compiler group is that the compiler is going to help shape the new APIs and their direction in general. Also, with .NET, you can make a case for either group since there's a common runtime. It's abstracted from the OS, but it also provides services to applications...

Anyhow, as long as Microsoft publishes its APIs in advance, and gives the other compiler-writers a fair shake, I don't care where they put it. But I think it'll be a while before we see that happening.

Also, I don't see any problems with the article as-is. Not only does Visual Studio contain many compilers, but many people call it (it usually being Visual C++) 'the Visual Studio Compiler'. Also, since pretty much all the compilers that Microsoft is pushing now are in Visual Studio, I thought it was pretty clear. At least, I understood what the author was saying. :)

Here are the compilers in question; I really doubt that Microsoft would switch to another compiler if at all possible; even if they wanted to, it would likely be a lot of work to get everything to compile. And they wouldn't want to use a competing project, much less contribute source. And contributing to real Free Software? Hah. I think they'd all quit before then.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall

Topical, yet not really.. (2.66 / 9) (#10)
by Sheepdot on Sun Dec 17, 2000 at 11:17:21 AM EST

This is somewhat off-topic and all, but I was wondering if anyone here in the k5 community actually thought that a breakup of MS would be *good* for the customers?

This topic brings up an especially good point where it would *not* be good for the consumer. This doesn't matter if you are the majority of the k5 community and you run Linux/FreeBSD as your main OS, but what about those of us who only use it for programming and other net-specific stuff?

And, for the record, I saw absolutely nothing wrong with MS integrating the browser with the OS. IE was MUCH stabler that way, and as a whole, loads faster. Netscape gets preinstalled with every Linux distribution I've ever used, so I don't know what the big tiff was with MS.

Especially when neither company charged a dime for their product. Kind of confuses me.


Actually... (3.40 / 5) (#11)
by Canthros on Sun Dec 17, 2000 at 11:32:35 AM EST

IIRC, Netscape's browser wasn't free at the time Microsoft released their browser. At least, I'm pretty sure that the Gold editions of Navigator were supposed to cost money, and that Navigator in general was only free for academic use. I think.

--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
[ Parent ]
Actually... (3.83 / 6) (#15)
by pb on Sun Dec 17, 2000 at 12:13:14 PM EST

I never thought MS was good for the customers in the first place, so of course I think a world without MS would be a good thing. AFAICT, they stopped caring about the power users around DOS 5.0. Once Win '95 came out, I switched to Linux; I just wish I had discovered Unix sooner...

There are tons of Windows development tools out there; I linked to most of them already. However, without Windows, it wouldn't really matter.

IE was stabler integrated into the OS? The whole idea of that frightened me. That was what made NT unstable in the first place; they moved the graphics drivers into the kernel. If you think that's a bad idea, try moving core parts of a web browser there...

The Netscape Browser wasn't preinstalled with RedHat until Netscape made it free, and I think also after they started work on Mozilla. (I checked, and it was RedHat 5.1; they bundled Netscape 4.05) Before then, you had to get it separately. Either way, you can always choose not to install it, though; it's bundled, not integrated. Nowadays, Internet Explorer is installed in Windows no matter what. If you don't want that URL-viewing capability bloating your OS, you have to rip it out by hand, which involves using (at least parts of) an old version of Windows...

And yes, Netscape used to charge for the Gold version, until Microsoft released IE and made it free. I think the real turning point was around IE4, but realize that Microsoft sunk money into this losing project until then, just to try to drive Netscape out of business; IE 3.0 really sucked. It had nothing to do with the consumer, but if you look at what happened to web standards, I'd say it definitely didn't help.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Apples meet oranges. Oranges meet apples. -NT (1.50 / 4) (#22)
by tetsuo on Sun Dec 17, 2000 at 05:02:15 PM EST



[ Parent ]
Customers/consumers (3.00 / 4) (#24)
by Spinoza on Sun Dec 17, 2000 at 05:43:10 PM EST

You seem to be asking whether or not we think the break-up of MS would be good for MS customers. You then treat the answer to this question as though "MS customers" is equivalent to "consumers" (meaning "all relevant consumers"). Forgive me if I have misinterpreted your intention, but this is missing the point of anti-trust law slightly.

Breaking the world up into MS customers and non-MS customers is not really acceptable in this case. The idea of anti-trust law is that consumers will have more than one place to go for their product. Those who choose to remain loyal to MS may well suffer. Those who choose to make use of the less monopolised market may benefit. It's not a question of "harm to MS customers".

The quality of MS products is not relevant to "good or bad for the consumer" because the idea is for other companies to find a place in the market and provide competing products. Faced with competition, all companies involved will have to compete on quality, as well as price. The assumption you make is that MS products couldn't be a good deal better than they are, and that MS is something worth protecting. I'm not convinced that the break-up will damage the ability of the two halves to build their products.

[ Parent ]

Another Option (3.25 / 8) (#13)
by Canthros on Sun Dec 17, 2000 at 11:54:19 AM EST

Right now, Microsoft's compiler is pretty heavily tied to an IDE. There's certainly nothing stopping you from not using the DevStudio IDE and using the compiler directly, so why not have the compiler be considered part of the OS? Distribute that puppy with the libraries in 'Professional' or 'Developer' versions of the OS and let third-parties provide solutions for IDEs.

Of course, this could be problematic for the DOJ, who (if they're to remain consisten) would have to consider this the exertion of monopolistic power to prevent the entrance of other players into the Windows compiler market.

As it currently stands, there's absolutely nothing stopping anyone from writing a compiler for the operating system, so the OS division could also license their compiler code out as a reference implementation to third parties wishing to develop MS Windows compilers (one would expect such things to usually be heavily tied in with an IDE). As long as they license out that code without respect to the market share of their own compiler (it is, after all, a reference implementation), there should be no problems of monopolistic influence.

But that's just the C/C++ compiler. The compiler/interpreters for other MS languages ought to fall under the Apps end of the business.



--
It's now obvious you are either A) Gay or B) Female, or possibly both.
RyoCokey
Kinda, but not really (3.66 / 3) (#31)
by skim123 on Sun Dec 17, 2000 at 09:19:00 PM EST

Right now, Microsoft's compiler is pretty heavily tied to an IDE

With the .NET thing, the compiler can be purchased with the IDE (i.e., Visual Studio), or you can go and FREELY download the C# and VB.NET compilers with the ASP.NET Beta 1 Download: http://www.asp.net/

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


[ Parent ]
GNU make is your friend... (2.50 / 2) (#37)
by Ricdude on Mon Dec 18, 2000 at 01:01:13 PM EST

At work, we use GNU make and the command line compiler tools, and only touch the IDE for debugging work. It's easier for us to keep one set of makefiles up to date than update the makefiles for the unix platforms, and then update the windows project files. Also the visual studio IDE blows major chunks for any "custom build steps" (i.e. lex/flex/yacc/bison). The IDE tends to work well for the subset of programs that it is obviously designed for (custom database front ends), but as soon as you start to step out of that box (multithreading? custom graphics? Win32 API abuse?, multiplatform development?) the IDE tends to get in your way more than it helps. Technically, the only thing tying the compiler to the IDE is that they aren't distributed separately.

[ Parent ]
Academic (3.20 / 15) (#14)
by Simon Kinahan on Sun Dec 17, 2000 at 12:06:08 PM EST

Since nice Mr Bush won the election, the DoJ case will be stopped anyway.

Simon

If you disagree, post, don't moderate
Intel should write the compiler. (2.83 / 12) (#17)
by Dries on Sun Dec 17, 2000 at 12:46:24 PM EST

Intel should write the compile, the OS depertment the libraries.

A compiler compiles code against a specific target processor and NOT for a specific operating system. A compiler has no knowledge about the OS whatsoever. Unless you are using operating system dependend libraries (which is likely to be the case), you can compile OS independant code.

Yes, the low level libraries such as for example the filesystem stuff, should be (obviously) provided by the OS department as they are most likely used by their kernel as well.

Dries
-- Dries

Executable file formats (4.28 / 7) (#19)
by aphrael on Sun Dec 17, 2000 at 02:07:35 PM EST

A compiler compiles code against a specific target processor and NOT for a specific operating system.

Not necessarily. Different operating systems use different executable file formats --- which the compiler has to know about ... osmething tied directly to the hardware isn't going to allow for differences like ELF/PE, etc, and will lock all OSs into using hte same executable format --- or the OS manufacturer will have to convince the hardware/compiler manufacturer to support it, which requires close ties between the two.

[ Parent ]

Reference Compiler (4.00 / 2) (#43)
by jfpoole on Tue Dec 19, 2000 at 01:39:22 AM EST

Different operating systems use different executable file formats --- which the compiler has to know about ...

If memory serves correctly, the compiler doesn't care what executable file format is used, since that's for the linker to worry about. Remember, a compiler doesn't even have to emit object code -- some emit assembly, others a different HLL entirely!

Of course, if chip manufacturers were to start writing a common compiler, all platforms would have to agree on a suitable intermediate format (or at least be able to understand the common intermediate format). Not as bad as tying everyone to an identical executable format, but I can't help but think that some platform oddities would be lost. Whether that's good or bad depends entirely on the oddity.

As always, my thoughts on the subject.
-j

[ Parent ]

C/C++, maybe. (4.00 / 1) (#47)
by aphrael on Tue Dec 19, 2000 at 11:47:38 AM EST

The compiler doesn't care what executable file format is used since that's for the linker to worry about.

fair enough *for c and c++*. But other languages don't have the clear-cut compiler/linker distinction that c/c++ do ... and even then, if you're creating a world where the hardware manufacturer supplies the *compiler* but the OS manufacturer supplies the *linker*, aren't you depriving yourself of most of the theoretical benefits of having the compiler supplied by the hardware vendor?

[ Parent ]

Re: C/C++, maybe (4.00 / 1) (#53)
by jfpoole on Tue Dec 19, 2000 at 11:04:23 PM EST

fair enough *for c and c++*. But other languages don't have the clear-cut compiler/linker distinction that c/c++ do

Other languages may not even use a compiler (perl and python, for example)! Still, I don't believe I've run into any compiled languages where you couldn't have separate compilation and linking steps.

if you're creating a world where the hardware manufacturer supplies the *compiler* but the OS manufacturer supplies the *linker*, aren't you depriving yourself of most of the theoretical benefits of having the compiler supplied by the hardware vendor?

It depends on the benefits (I'm not sure they've ever been stated). I'd presume that the hardware vendor would produce a compiler that does a very good job of optimizing code (very possibly better than what the OS vendor could achieve). That benifit will still be there if the OS vendor writes the linker.

As for the benefit of not having secret APIs and such, that's not really a benefit you gain if the hardware vendor writes the compiler, since those APIs will be in the OS libraries (which wil be provided by the OS vendor).

I'm not sure what other benefits you could be thinking of, since those are the only two I can think of off the top of my head.

-j

[ Parent ]

Multiplatform OSes (4.00 / 2) (#44)
by jfpoole on Tue Dec 19, 2000 at 01:47:27 AM EST

Intel should write the compile, the OS depertment the libraries.

What about operating systems that run on a variety of different platforms? For example, Windows NT used to run on x86, PPC, MIPS, and Alpha -- if the chip vendor wrote the compiler for each platform, then there would be four different compilers that the OS vendor would have to target. While this may not seem like a big deal at first, remember each compiler has its own special set of quirks. Different things break on different compilers, and when it comes to languages like C++, different compilers tend to have different subsets of the language implemented.

The real problem arises when application developers wade into the fray. What worked on one hardware platform now breaks on a different one. Porting to different hardware running the same OS becomes more difficult than it already is. Not a good thing.

However, if the OS vendor writes the compiler itself, then you know ahead of time what language features you'll get under said OS, regardless of the underlying hardware. Of course, you'll still have to deal with bugs in the code generator, but that's better than dealing with bugs throughout the compiler.

As always, my thoughts on the matter,
-j

[ Parent ]

Who is doing it in free software? (3.28 / 7) (#18)
by maketo on Sun Dec 17, 2000 at 01:00:54 PM EST

Do the same people who write/maintain gcc write/maintain the free kernels/OSs around?
agents, bugs, nanites....see the connection?
pretty much yeah.. (3.66 / 3) (#33)
by enterfornone on Mon Dec 18, 2000 at 02:07:18 AM EST

Cygnus (now Redhat) maintain both GCC and glibc. The kernel isn't all that relevant because on a source level you mainly need to worry about API (ie libc) compatabilities, not kernel compatabilities. Of course, since it's all open, anyone can port the compiler to their OS.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]
err... (3.16 / 6) (#23)
by robbo42 on Sun Dec 17, 2000 at 05:36:36 PM EST

... wouldn't both of them end up making compilers?

When you think about it, a compiler is necessary for anyone writing software - I would suggest that if the breakup were to go ahead, whoever didn't get MS Visual Studio.NET (or whatever they're calling it this week...) would probably end up writing their own.

As for who would get the existing compiler/toolkit - well, in the "infinite wisdom" of those who "do" justice, I'd almost bet that it would be the apps division - after all, it is an app of sorts ;)

This is assuming, of course, that the breakup happens (and andyschm has a point here - it is a moot argument).

And another thing. Do M$ even use their own compiler "technology" for internal development?


Intel Inside: The world's most commonly-used warning label.
Why? (3.33 / 3) (#29)
by pb on Sun Dec 17, 2000 at 07:51:15 PM EST

Why couldn't they buy or license it from their other half?

I guarantee you the Apps people are going to need copies of the Windows OS, and the OS people are going to use the Apps for compatibility testing...

I'm pretty sure MS uses their own compiler; I searched some binaries for copyright strings, too...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Re: Why (3.00 / 1) (#49)
by kagaku_ninja on Tue Dec 19, 2000 at 03:17:25 PM EST

Talking to a former PowerPoint developer, I learned they do use their own compiler. They do not use MFC (no suprise there...) They also had an updated version of the 16 bit compiler that was not made available to the public (because M$ stopped supporting the 16 bit version of VC++ as part of their strong arm tactics in getting the Windows world to upgrade from 3.11)

[ Parent ]
Who should get $FOO (3.55 / 9) (#25)
by enterfornone on Sun Dec 17, 2000 at 07:14:33 PM EST

The truth is the DOJ have no idea what they are talking about when they talk of splitting up MS. Obviously Windows belongs to the OS group, Office belongs to apps. No doubt IE belongs to apps. Who gets the compiler? Who gets IIS (it's now intergrated into Win2000) ? Do the rest of the server apps (Exchange, SQL etc) belong to OS or apps. Who gets the Windows shell? On one hand obviously the OS needs a shell, on the other hand there's a lot of IE stuff in there. Who gets MSHTML.DLL? It's needed by explorer, active desktop, as well as IE. Who gets MFC?

It's fairly obvious that the DOJ didn't think at all of the implications of splitting MS.

--
efn 26/m/syd
Will sponsor new accounts for porn.
Maybe... (3.33 / 3) (#28)
by pb on Sun Dec 17, 2000 at 07:47:50 PM EST

Maybe they did think about it. Maybe they realized that the divisions are somewhat murky now, and they want to clean them up.

For instance, if the OS people get MSFOO.DLL version 4, then you can expect the platform to have that. Therefore, Word doesn't need that DLL. If it's needed for, say, a previous version of Windows that doesn't have that DLL, then you can expect to have that DLL in Word as well, or (if worse comes to worse) an OS upgrade will get installed from the same CD.

What, you say? An OS component in an App? This should be fine IMO as long as they get it from the OS people. (third-party apps do this all the time; it stands to reason that Microsoft apps could too; I remember getting the Service Pack 4 upgrade for NT from a Compuserve disk, of all things...)

With something as big and kludgy as Windows, this sort of thing is bound to happen sooner rather than later, so I'm sure they'll work out some provision for it. They really are pretty intelligent people. (say, if said DLL is required for said application to run, and that application can't reasonably expect that said DLL will be installed by default...)

However, integrating a web browser into the OS is right out. :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
MacOS Compiler (3.00 / 6) (#26)
by J'raxis on Sun Dec 17, 2000 at 07:19:46 PM EST

The MacOS has the Macintosh Programmer's workshop (MPW), made by Apple itself.

The most popular development program for Macintosh is, however, CodeWarrior, AFAIK.

There's also a program called ResEdit, which is used to create and edit the resources (items such as dialogs, controls, icons, etc) used in an application. ResEdit is also made by Apple.

-- The Macintosh Raxis

[ J’raxis·Com | Liberty in your lifetime ]

MPW vs. CodeWarrior (none / 0) (#56)
by DickBreath on Sat Dec 23, 2000 at 07:01:13 PM EST

I'm a few years out of touch with Mac OS development. But my understanding of the present day situation is as follows.

Apple made their own really good CLI environment called MPW (Macintosh Programmers Workshop). In fact the influence of unix on it is very evident and in the rich set of supporting utilities and their semantics, scripting, etc. Third parties could develop tools which ran inside MPW (like writing a CLI program). Thus other compilers, or other utilities are available. (i.e. a couple of grep-like tools that are faster/better than Apple's, etc. Most third party compiler products, also happen to include a variation on their compiler packaged as an MPW tool to run inside Apple's CLI.)

MPW was Apple's development tool for ages. All developer examples provided in MPW. Documentation assumes MPW.

Meantime, everything is throughly published and documented, as everything on the Mac has ALWAYS been. And third party compilers blossom and flourish.

Symmantec's C++ compiler turned to absolute crap as of the 8.0 release. They were late with PowerPC support. MetroWerks saved the day. Not only good PPC support, but total cross development. And cross language. And then later, cross platform -- which they then extended to every known platform and embedded system under the sun.

A few years back as Apple's fortunes turned around, they basically quit officially supporting MPW. AFAIK. It is now available for download. And it is now free, instead of $$.

As far as I can tell, though, MetroWerks CodeWarrior seems to be what everyone actually uses, including Apple -- even for OS development(!) AFAIK. (As I said, I'm a couple years out of touch with this.)

[ Parent ]
Do you understand the issues well enough? (3.45 / 11) (#27)
by GreenCrackBaby on Sun Dec 17, 2000 at 07:27:20 PM EST

My personal opinion is that by having the OS group responsible for the compiler would be better, because: It would result in a better compiler, more effectively integrated into the OS.

Since you've obviously missed the whole point of the DoJ case, I voted this story -1.

Let's say you are talking about a C++ compiler (you really didn't fill in many details). If you allow the OS division to produce this, you create a situation that exists now: hidden APIs that give everyone else unfair handicapps. If you force all OS APIs to be publicly available, then anyone can write the compiler.

to what end? (3.60 / 5) (#35)
by ameoba on Mon Dec 18, 2000 at 09:57:52 AM EST

What would the point be in having undocumented APIs, if all the OS group is writing would be the OS and the compiler? I could see an argument for something being left undocumented through sheer laziness, but what's the benefit to them if they don't bother documenting?

Or, are you making reference to the existing undocumented APIs continuing to be so, being left in for the sake of the Apps group?

Since the OS group wouldn't be allowed to write non-OS software, what point would handicapping developers be? Forcing poorer quality apps to exist for their OS would only reflect negatively on the OS...

[ Parent ]
Basic comp sci? (3.00 / 4) (#34)
by armag0n on Mon Dec 18, 2000 at 02:28:27 AM EST

I'll ignore all references to the DOJ case, and just answer ameoba's orignal question, who should write the compiler if Microsoft gets the split?

I was taught in basic comp sci courses that compilers are systems software. If you accept this, then the OS group should write the Visual Studio compiler. Indeed, it kinda makes sense to have the OS group take care of the compiler because they are the group that are going to know the OS best and they are therefore in the best position to write a program that has to intimately interface with the OS.

However, I can see the point of those who think that the apps group should write the compiler because of the long history of underhandedness by Microsoft and their inclusion of many undocumented system calls.

But, when you think about it, there is nothing going to stop collusion between the OS group and the Apps group at Microsoft. So, in effect, whoever writes the compiler doesn't matter, it'll still be doing Microsoft's bidding.

You apparently Don't Get It (3.00 / 2) (#50)
by gauntlet on Tue Dec 19, 2000 at 03:49:14 PM EST

The entire point of splitting them up is to eliminate collusion between the OS group and the Apps group. This will be done by placing judicial supervision on activities between the two organizations, or something like that.

And I, for one, believe it will work. Each of the two companies will have its own bottom line to be looking out for, and that self-preservation will involve following the rules.

Into Canadian Politics?
[ Parent ]

Split it, kind of... (4.14 / 7) (#36)
by Ricdude on Mon Dec 18, 2000 at 12:47:38 PM EST

CL.EXE, LINK.EXE, LIB.EXE, RC.EXE, and any other "atomic" utilities for actually manipulating source files into executables and libraries should go to the OS division.

Visual Studio (MSDEV.EXE) should go to the apps division.

This way, the OS division gets to tune the compiler for optimizations required for kernel development, whereas the apps division gets to work on the pretty gui to tie it all together for the programming hordes.

What's less clear to me is who should get stewardship of MFC. Scratch that. OS division gets that too, as several of the gui tools will require the toolkit...

Answer (3.00 / 2) (#46)
by Biff Cool on Tue Dec 19, 2000 at 10:46:24 AM EST

No one gets control of the MFC it dies the death it deserves 1000 times over Windows developers get free copies of it on CD to BURN and then leave hanging in the street for people to spit on like some long gone fascist dictator.

God that felt good to get out... sorry


My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
The compiler group has all the brains (4.28 / 7) (#40)
by scross on Mon Dec 18, 2000 at 04:31:11 PM EST

I've been watching the compiler group for about ten years now. It seems very clear since version VC++2.0 that the lines between application programming and system programming began to blur with the introduction of OLE 2.0

I was sitting next the lead PageMaker programmer from Aldus at the OLE 2.0 developers conference workshop who pointed out that in OLE 2.0, Microsoft began to capitalize on internal knowledge of the class virtual function table to get OLE Automation working. This, of course, forces all compiler vendors to implement virtual functions the same way. At the time Borland and Watcom together had majority market share. This change significantly affected their ability to compete.

A few years later I was talking to another programmer complaining how VB and VC++ was making it too easy for stupid people to call themselves a windows programmer. He basically said: "... well of course they're easy to use, Bill [Microsoft] doesn't want to pay for good programmers anymore than any other company." This lead me to say: "... so he puts all his brains into the compiler group to make application development as easy as possible. Hmm ... this also increases market share because the targeted code is so tied to the windows platform that it is hopeless to try to run it anywhere else."

We sort of stared at each other in how astonishingly simple this was.

Forget Internet Explorer, that's peanuts compared to how devious control of the compiler is.

For that matter, consider the ledgend of the original UNIX compiler.

Cheers, Sarah

Another effect.. (none / 0) (#55)
by DickBreath on Sat Dec 23, 2000 at 06:47:35 PM EST

VB and VC++ was making it too easy for stupid people to call themselves a windows programmer

so he puts all his brains into the compiler group to make application development as easy as possible. Hmm ... this also increases market share because the targeted code is so tied to the windows platform that it is hopeless to try to run it anywhere else

There is yet another effect. Stupid people writing code probably results in inefficient code, poor design, poor choice of algorithms, etc. Thus code bloat.

Code bloat a benefit? To Microsoft yes. It helps perpetuate the cycle of hardware upgrades, and then the inevitable software upgrades which follow, which in turn trigger a new cycle of hardware upgrades. Lather, rinse, repeat.

[ Parent ]
Doesn't Matter (2.50 / 4) (#41)
by jakeeboy on Mon Dec 18, 2000 at 07:33:28 PM EST

Reading the comments it appears that most believe you need the compiler to be intergrated with the OS but if you look at the OSS *nix's you see something different. The compiler used is gcc but that is not maintained by anybody in any of the OSS *nix's. For my vote the compiler should become open source. There no one in particular is in control, both the app division and os division end up having to use the same one and tailor the OS and APPS towards the working compiler. Visual Studio then becomes another app with that division.
"I'm a joker, I'm a smoker, I'm a midnite toker, Get my luvin' on the run"
This seems simple (2.42 / 7) (#42)
by rw2 on Mon Dec 18, 2000 at 08:55:14 PM EST

A compiler is not an Operating System.

A compiler is an application.

To be a little less pithy though. The bundling of the compiler group with the operating system would assure that they would continue with the most predatory and harmful of their practices. That of ignoring standards and integrating features with Windows as it is in their favor to do so thus continueing to control the OS market through monopoly.

However, if the compiler group were forced to fight for their lives without the cash cow OS group supporting their efforts then you would see VC++ for Amiga (well, something other than Windows anyway) :-)

--
Poliglut, because the oval office has no corners.

Not so simple (3.00 / 1) (#45)
by Biff Cool on Tue Dec 19, 2000 at 10:43:19 AM EST

A compiler is not an Operating System.

A compiler is an application.

Actually in a microkernel environment pretty much everything is an "application", IE is a part of the OS (whether that's good or bad is a whole other flamewar), it may not be incapable of being removed but it is integrated in.  IE is also an application.  In MacOS the Finder is a very important piece of the OS, it's also an app. The list goes on and on: defrag, fdisk, format, command.com

To be a little less pithy though. The bundling of the compiler group with the operating system would assure that they would continue with the most predatory and harmful of their practices. That of ignoring standards and integrating features with Windows as it is in their favor to do so thus continueing to control the OS market through monopoly.

Firstly why should Microsoft stop putting features into their OS?  Isn't that what's called improving your product?  If that's how they controlled the OS market then I had them wrong all along.  Secondly there aren't OS Standards so there's nothing for them to ignore.  MS in alot of cases does good to standards, granted it's only when they're behind the competition so they can "embrace and break-cervical" them.  For what it's worth last I read IE5.0 for the Mac was the most standards compliant browser out there. And I've got both IE5.5 and Mozilla running on NT4 and IE still kicks the pants off of it.  'Zilla takes at least 3 times as long to load.  And I'm not sure about standards compliance but I imagine it's still getting kicked around by IE.  The point of this is that Microsoft as much as we all hate them releases some good products, they also release cluster-fuck bloated pieces of shit like the Office Suite, and because there isn't any serious competition (I've tried both Corel and StarOffice and they make me want to die), they don't have to do anything remotely competent.  I want the compiler to go to the OS group just to be as far away from the Office team as possible.  The reason MS got brought up on anti-trust charges is for unfair business practices, not just having a monopoly, so if you're going to hate them and you should hate them for that... and for Office

However, if the compiler group were forced to fight for their lives without the cash cow OS group supporting their efforts then you would see VC++ for Amiga (well, something other than Windows anyway) :-)

Seriously have you ever used the Visual Studio Suite?  It's one of the best interfaces I've found on a Windows box.  Granted I haven't played with anything since Borland 5 (on a side note borland 4 still has better syntax coloring).  The VS tools work very well and they have alot of nice features (yes including the app wizard someone please put me out of my misery).  And as for the OS group being the cash cow I'd bet any one of the teams makes as much as the OS group, my work payed somewhere around $1500 for Visual Studio 6, and god knows how much for Office?

Did I mention how much I hate the Office Suite?


My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
Oh, it is too (4.00 / 1) (#52)
by rw2 on Tue Dec 19, 2000 at 06:59:37 PM EST

Actually in a microkernel environment pretty much everything is an "application", IE is a part of the OS

IE is bundled with the OS. It isn't part of it. There is, though MS doesn't like to admit it, a difference.

Firstly why should Microsoft stop putting features into their OS? Isn't that what's called improving your product?

Because it is illegal to use a monopoly to gain market share in an adjacent market.

Secondly there aren't OS Standards so there's nothing for them to ignore.

First your wrong. But it's a minor point.

My point was that their secondary tools ignored standards. Including their compilers. Again using your monopoly to gain market share in adjacent markets is illegal. In this case the compiler arena. If on top of that you use your new monopoly to create non-standard implementations then you are on even more shaky ground.

Seriously have you ever used the Visual Studio Suite? It's one of the best interfaces I've found on a Windows box.

Yes. For years. In my case it wasn't ignorance that bread contempt. It was intimacy.

Saying it is one of the best interfaces on a Windows box is a bit like saying your 82 Chevette was the fastest of it's product line though.

--
Poliglut, because the oval office has no corners.
[ Parent ]

Is not, is not, is not, lalalalalala (none / 0) (#54)
by Biff Cool on Wed Dec 20, 2000 at 02:37:03 PM EST

IE is bundled with the OS. It isn't part of it. There is, though MS doesn't like to admit it, a difference.

IE isn't bundled with the OS if it were you could just delete all it's parts and have a fully functioning OS still.  Parts of IE are used by the Explorer Shell, and need to be there for functionallity.  Technically I suppose all of IE isn't required just certain dll's

Because it is illegal to use a monopoly to gain market share in an adjacent market.

So what can they package with Windows that doesn't have an adjacent market? Notepad, defrag, telnet, scandisk, these all are adjacent markets, they all have at least shareware competitors.  It's not adding features to an OS that's illegal whether you have a monopoly or not.  Besides which the browser war wasn't what I was talking about, you said that by adding features to the OS they were controlling the OS market by monopoly, I still don't see what's wrong with an OS monopoly based on having lots of features.

My point was that their secondary tools ignored standards. Including their compilers.

VC6 holds to the ANSI C++ standard fairly well, it barf on some of your more complex template stuff and there's a problem with for loops.  Don't remember how VC5 does but that came out while the standard was still in draft anyways.

Again using your monopoly to gain market share in adjacent markets is illegal. In this case the compiler arena.

I'd imagine they grabbed market share with their compilers by using COM/OLE/ActiveX as much as anything.

If on top of that you use your new monopoly to create non-standard implementations then you are on even more shaky ground.

I'm not sure what you mean by that. Non-standard implementations of what?


My ass. It's code, with pictures of fish attached. Get over it. --trhurler


[ Parent ]
Look at borland, symantec etc... Give it to both (4.20 / 5) (#48)
by bored on Tue Dec 19, 2000 at 02:38:55 PM EST

Having worked on one of the named OS's I can agree that it is a good thing if the OS people have some control over the link phase of the build process. I disagree though that the OS division should have exclusive control over this. It is perfectly possible for the OS division (which usually runs standard make type build themselves) to provide an 'open' interface to the OS loader system and maintain a reference C compiler/linker/assembler.


The apps division though should own the MSDEV stuff. Probably their own implementation of the compiler and linker as well. The direct tie between the OS and the compiler is one of the reasons that Borland isn't doing as well as they should be. If the OS group controls the primary compiler then competitors have to wait for the OS to come out to reverse engineer the formats to make their own stuff work with it. In the mean time there is this 6 month lead time (or more) where the only compiler that works with the 'new' OS is the one from the OS manufacturer. If MSDEV and VC are owned by the apps division then any critical OS changes will have to be made public before the release of the OS so early developers can use third party development tools to create applications to match the release date of the OS. Without this a single company in this case the OS division of M$ will control the primarily application development environment which forces developers back into the same situation they already are in. Either us the M$ tools or lag behind the competition because your tool developer has to wait on the M$ OS/compiler release schedule to work on their tools.


About the only real way to assure that changes are properly opened to the public and everyone doing tool work is on equal footing is to take the OS specific sections of the compiler and give them to a third party. Sort of like an open consortium where the reference compiler/linker (which is what is used to compile the OS) development source is always open. That way when M$/OS needs to make a change they simply make the change to the open reference compiler/linker and everyone can look at the changes to integrate them into their own source bases.



Re: Who should get the Windows compiler? (2.75 / 4) (#51)
by Stormbringer on Tue Dec 19, 2000 at 05:27:11 PM EST

It's an app.There's no point in giving it to the OS group. This is Microsoft, remember? No way will you ever be allowed to compile your own Win32 kernel.

Who should get the Windows compiler? | 56 comments (42 topical, 14 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!