One of the biggest advantages of COM over CORBA is a *big* speed difference when running in-proc, while maintaining the same speed as CORBA as out-proccess & out-machine.
What about something other than plain text? I doubt that plain text copying has changed in the last couple of years, or that it was hard to get it right the first time.
But on Windows, you can copy *structured* text, tables, etc, with no difficulity at all.
That is much more impressive than merely a text copying.
It's wrong.
You should try building an ActiveX in VC6.0
The whole thing is (mostly) wizard-generated boiler-proof code (ATL) which gives you all you can want (and more).
This clears up everything that is related to COM itself and leave you dealing with the bussiness logic you are trying to implement, rather than getting distracted in the details.
1 & 3 were important factors, but it's 2 that makes a platform into a success.
Having killer applications is something that any platform needs, and MS realized this in a very early stage of the game.
Ms tradionally has been very friendly to developers, both as a tool provider (quite frankly, their developing tools are second to none. For crying out loud, VC++6 is 4 years old, and the only thing better out there is VS.NET.)
Compare that to IBM, frex, which made you pay for OS/2 documentation & help.
It might help understanding why it was Windows and not OS/2 that got the killer applications.
ActiveX is just a super-enhanced COM object (basically, it supports a lot of standard interfaces, which allows you to do some neat stuff with any object).
But it's still COM, and COM is totally language blind.
I don't think that you'll find a programming language targeting win32 without some COM binding. It's a must for Win32 programming.
Granted, it may be a bit ugly to work with ActiveX via IDispatch on C (shudder!), but there are ways to go around it with wrappers.
> It probably makes a big difference that component architecture is an afterthought in MS's toolset, but a basic part of the Delphi design.
I agree that Delphi is a better language for some things, but I'll have to strongly disagree with you on this statement.
Component architecture is far beyond being an afterthought for MS.
To put it mildly, Windows is heavily depended on components. To the point where it wouldn't boot without COM. Certainly wouldn't be able to function.
New APIs are now more and more COM interfaces rather than C-style functions. (DirectX is all about COM, frex)
And MS provides some excellent tools (in that, as in pretty much any other development area) for creating compnents.
What kludge are you talking about, for crying out loud?
A> Why use a Relational data base to store hirercial data? A HDB is *much* faster than a comparable RDBS, because it architecture is much simpler.
B> All of the things that you mention could be solved with a good, high-end file system. Forgive me for intreducing a non-Unix concept, but I didn't have the chance to work with file systems there. But on NTFS, you can have pretty much anything you list here, including triggers (called repharsed points) and change journal, additional properties and notes can be handled via streams.
Other systems, for example, provide more complete solution, in that they provide journal data (as opposed to journaled meta data only on NTFS), which can help increase your stability.
All in all, I don't see they reason to go with an RDB instead of a good, high end, file system or a HDB.
Do you mind taking a pick on Linux source and tell me exactly where you are counting those 0.5 million LOC vs. 35 millions of Win2K?
I can assure you that Win2K kernel is much smaller than Linux's kernel.
For a start, it's Linux who uses the monolithic design, while Win2K uses a modified micro-kernel design.
When MS talks about Win2K being 35MLOC, they are talking about the whole thing. And this contain so many things beside a kernel that I can't begin to count.
But please tell me, what is the sum in KLOC of the following products?
Linux kernel
KDE
KDE-Parts (equilent to Windows' COM, does it support language and location trasperancy? If no, add CORBA, which does)
Mozilla
Apache
perl & python
J2EE implementation
Basic applications (text editor, word processor, image editor, etc)
Networking stack
Printing services
As a matter of fact, Windows' prices has remained fixed for quite some time, from Win95 & NT 3.1 or earlier.
Another thing to consider is that since Windows' code base is being so heavily tested, there would come a time when there wouldn't *be* security bugs in them.
Or at least not that many.
Of course, some of the *design* decision in MS are at fault here, not the implementation itself.
For example, I don't know off hand of any security flaw in NT itself (the OS, not the services like IIS), but putting services as SYSTEM is a big mistake.
In essense, you take NT's wonderful security features, and eliminate them!
IIS shouldn't be a running as SYSTEM, that is a start that would make owning boxes via unpatched IIS *much* harder, and shouldn't have big ill affects. (Except having to consider what rights IIS should get by default, and those should be minimized, not maximized.)
Anyone can take the CLI and do whatever they want with it, like Ximian does.
MS doesn't have any control over it anymore.
What they *do* have control of is their BSD.NET version, which you can use, or modify for non-commercial uses.
They don't *want* 100% compatability, they basically says, "Yes, you won't have 100% code portability between Windows & BSD, but that is fine from our point of view, because we aren't going to force our UI model on X server, or NT security on Solaris."
The idea is that you have all the basic services, and your code logic will port, the only parts that you'll have to change are parts that rely on classes not found on the platfrom, and those you can write (or get from the.NET provider, more likely) to get the functionality that you need.
*Cough* Do you know what raw sockets are?
9x never had them, just in case you weren't aware of it.
NT starting from 2000 has it. And Linux and all the other *nixes had it for a long time.
Well, considerring that MS wouldn't be the one to do the converting, would in fact have to open its source code to three other players in an auction (I bet on IBM & Sun, and maybe Apple as well).
There goes the "they will make it suck" arguement.
But who here thinks that what those companies will do is take WINE, fix all the problems that it currently have with Office (and it doesn't have that many) and just compile it with winelib ?
It should be a much shorter work than to convert Office to Linux.
Also, Wine is a much smaller application than Office, so porting it to other dist/unixes (and no, that isn't always as easy as recompile) should be much easier.
The advantage to the community is that we would get a much improved WINE, I don't know about you, but IMHO, if WINE can manage to run Office well, then there won't be much left to improve in it.
Win 2000 - NT 5
Win XP - NT 5.5
So you are quite correct in what you are saying.
Win XP is basically a big change of the UI, many compatability improvements, and some nice extras.
Most of the framework exists on Win2K already, which you can see if you will study some of the stranger UI API that appeared on Win2K.
Win9x had a single purpose, in which it succeed admirably well, move people from writing DOS-style apps to writing NT-style apps.
9x simply allowed you to write them both, and enoucrage (mainly through DX, IMHO) writing NT style apps than DOS applications.
I'll be certain to check this out, it sound cool.
But I would like to point out one thing that isn't very good in hiding local/network calls from the programmers.
There is a *lot* that can goes wrong in a network call that can't go wrong in a local call.
Therefor, network calls should've options that allows me to check on what is going on in this call.
Basically, this put you on unsynch-calls, which are much harder than straight calls.
I certianly wouldn't like to do it for anything local.
Question: What happens when there is an error in the fileserver and it crashes, how it affects the programs that uses it, and the system itself?
But if you take some guy who *doesn't* know the C++ inside and out (and that *is* the most common case), and what kind of a program would he write?
The same programmer would create a much more stable program in Ada.
Ada allows you nearly all the freedom of C++, with a lot more cool stuff beside, without you having to worry about many things that you will have to in C++.
Ada saves you a lot of the trouble that C++ programs suffer from.
Oh, and BTW, the only Ada implementation that has a garbage collection (AFAIK) is the JVM one.
Ada catches way more errors at compile time than most other languages.
It also has quite a bit of runtime checks to make sure that nothing nasty happens.
In that, it's much like Java.
However, usually, if an Ada program compiles, the only bugs it has are logical ones.
I would say that Ada programs are more stable than C++ programs because of this.
And yes, great programmers can create C++ programs that are just as stable as the average Ada program.
The difference IMO is that an *average* Ada programmer can create programs much more stable than another programmer of the same level, that is working with C++.
And yes, there is a kernel in Ada, it's called AdaOS (http://www.adaos.org/)
Who the *hell* is talking about writing a kernel using Perl?
As for C#, as a matter of fact, there *are* people trying to build a kernel using C#.
And for more robust than C++, that isn't very hard.
To mention *the* one language that I think should be used for kernel programming, Ada.
It's *way* more stable than C++, has the same plexibility, and if you are satisfied with the stability of your code, you can supress any/all of the checks that you want.
I think that if you need to use different language to break the task to small parts, then you might want to review your design methods.
You are supposed to do it anyway, after all.
Unless you tend to make the mistakes in the calling code.
I did, and spent a couple of hours trying to find out what is wrong, because I knew what I *meant* to put in the calling code, and never tried to look up what I actually wrote.
First, I think that a developer needs to know several languages, both LLL and HLL.
Now, I think that it's prefferable to do a project in one language, that way it's much easier to mention, and you don't have to move from one way of thinking to the other.
That said, there are some inherited weeknesses and strengths to languages, which is why I think that sometime it's important to mix languages. (For example, creating a fortran library to do the number crunching, or c dll for string handling)
When I mix languages, I usually end up in writing roughly 90% of the application in one language, and using another just to support its weak points (VB for major string handling, frex.)
Slashdot Mirror
One of the biggest advantages of COM over CORBA is a *big* speed difference when running in-proc, while maintaining the same speed as CORBA as out-proccess & out-machine.
> and OpenGL hardware support
They got that right, at least.
What about something other than plain text? I doubt that plain text copying has changed in the last couple of years, or that it was hard to get it right the first time.
But on Windows, you can copy *structured* text, tables, etc, with no difficulity at all.
That is much more impressive than merely a text copying.
It's wrong.
You should try building an ActiveX in VC6.0
The whole thing is (mostly) wizard-generated boiler-proof code (ATL) which gives you all you can want (and more).
This clears up everything that is related to COM itself and leave you dealing with the bussiness logic you are trying to implement, rather than getting distracted in the details.
1 & 3 were important factors, but it's 2 that makes a platform into a success.
Having killer applications is something that any platform needs, and MS realized this in a very early stage of the game.
Ms tradionally has been very friendly to developers, both as a tool provider (quite frankly, their developing tools are second to none. For crying out loud, VC++6 is 4 years old, and the only thing better out there is VS.NET.)
Compare that to IBM, frex, which made you pay for OS/2 documentation & help.
It might help understanding why it was Windows and not OS/2 that got the killer applications.
ActiveX is just a super-enhanced COM object (basically, it supports a lot of standard interfaces, which allows you to do some neat stuff with any object).
But it's still COM, and COM is totally language blind.
I don't think that you'll find a programming language targeting win32 without some COM binding. It's a must for Win32 programming.
Granted, it may be a bit ugly to work with ActiveX via IDispatch on C (shudder!), but there are ways to go around it with wrappers.
> It probably makes a big difference that component architecture is an afterthought in MS's toolset, but a basic part of the Delphi design.
I agree that Delphi is a better language for some things, but I'll have to strongly disagree with you on this statement.
Component architecture is far beyond being an afterthought for MS.
To put it mildly, Windows is heavily depended on components. To the point where it wouldn't boot without COM. Certainly wouldn't be able to function.
New APIs are now more and more COM interfaces rather than C-style functions. (DirectX is all about COM, frex)
And MS provides some excellent tools (in that, as in pretty much any other development area) for creating compnents.
What kludge are you talking about, for crying out loud?
Well NTFS can handle up to 16 exabytes...
That is what Lotus tried to do, Excel didn't bother to react, and you know where they are today, don't you?
A> Why use a Relational data base to store hirercial data? A HDB is *much* faster than a comparable RDBS, because it architecture is much simpler.
B> All of the things that you mention could be solved with a good, high-end file system. Forgive me for intreducing a non-Unix concept, but I didn't have the chance to work with file systems there. But on NTFS, you can have pretty much anything you list here, including triggers (called repharsed points) and change journal, additional properties and notes can be handled via streams.
Other systems, for example, provide more complete solution, in that they provide journal data (as opposed to journaled meta data only on NTFS), which can help increase your stability.
All in all, I don't see they reason to go with an RDB instead of a good, high end, file system or a HDB.
> Or perhaps having similar code in one routine executing over and over again rather than being in a function where it belongs in the first place.
This might be in purpose, you know, to save you the time you spend pack & unpacking the variables from the stack
Do you mind taking a pick on Linux source and tell me exactly where you are counting those 0.5 million LOC vs. 35 millions of Win2K?
I can assure you that Win2K kernel is much smaller than Linux's kernel.
For a start, it's Linux who uses the monolithic design, while Win2K uses a modified micro-kernel design.
When MS talks about Win2K being 35MLOC, they are talking about the whole thing. And this contain so many things beside a kernel that I can't begin to count.
But please tell me, what is the sum in KLOC of the following products?
Linux kernel
KDE
KDE-Parts (equilent to Windows' COM, does it support language and location trasperancy? If no, add CORBA, which does)
Mozilla
Apache
perl & python
J2EE implementation
Basic applications (text editor, word processor, image editor, etc)
Networking stack
Printing services
And the list goes on...
As a matter of fact, Windows' prices has remained fixed for quite some time, from Win95 & NT 3.1 or earlier.
Another thing to consider is that since Windows' code base is being so heavily tested, there would come a time when there wouldn't *be* security bugs in them.
Or at least not that many.
Of course, some of the *design* decision in MS are at fault here, not the implementation itself.
For example, I don't know off hand of any security flaw in NT itself (the OS, not the services like IIS), but putting services as SYSTEM is a big mistake.
In essense, you take NT's wonderful security features, and eliminate them!
IIS shouldn't be a running as SYSTEM, that is a start that would make owning boxes via unpatched IIS *much* harder, and shouldn't have big ill affects. (Except having to consider what rights IIS should get by default, and those should be minimized, not maximized.)
Anyone can take the CLI and do whatever they want with it, like Ximian does.
.NET provider, more likely) to get the functionality that you need.
MS doesn't have any control over it anymore.
What they *do* have control of is their BSD.NET version, which you can use, or modify for non-commercial uses.
They don't *want* 100% compatability, they basically says, "Yes, you won't have 100% code portability between Windows & BSD, but that is fine from our point of view, because we aren't going to force our UI model on X server, or NT security on Solaris."
The idea is that you have all the basic services, and your code logic will port, the only parts that you'll have to change are parts that rely on classes not found on the platfrom, and those you can write (or get from the
*Cough* Do you know what raw sockets are?
9x never had them, just in case you weren't aware of it.
NT starting from 2000 has it. And Linux and all the other *nixes had it for a long time.
> Of course if you are on a MS platform...
You would use hardlinks...
Well, considerring that MS wouldn't be the one to do the converting, would in fact have to open its source code to three other players in an auction (I bet on IBM & Sun, and maybe Apple as well).
There goes the "they will make it suck" arguement.
But who here thinks that what those companies will do is take WINE, fix all the problems that it currently have with Office (and it doesn't have that many) and just compile it with winelib ?
It should be a much shorter work than to convert Office to Linux.
Also, Wine is a much smaller application than Office, so porting it to other dist/unixes (and no, that isn't always as easy as recompile) should be much easier.
The advantage to the community is that we would get a much improved WINE, I don't know about you, but IMHO, if WINE can manage to run Office well, then there won't be much left to improve in it.
Win 2000 - NT 5
Win XP - NT 5.5
So you are quite correct in what you are saying.
Win XP is basically a big change of the UI, many compatability improvements, and some nice extras.
Most of the framework exists on Win2K already, which you can see if you will study some of the stranger UI API that appeared on Win2K.
Win9x had a single purpose, in which it succeed admirably well, move people from writing DOS-style apps to writing NT-style apps.
9x simply allowed you to write them both, and enoucrage (mainly through DX, IMHO) writing NT style apps than DOS applications.
I'll be certain to check this out, it sound cool.
But I would like to point out one thing that isn't very good in hiding local/network calls from the programmers.
There is a *lot* that can goes wrong in a network call that can't go wrong in a local call.
Therefor, network calls should've options that allows me to check on what is going on in this call.
Basically, this put you on unsynch-calls, which are much harder than straight calls.
I certianly wouldn't like to do it for anything local.
Question: What happens when there is an error in the fileserver and it crashes, how it affects the programs that uses it, and the system itself?
But if you take some guy who *doesn't* know the C++ inside and out (and that *is* the most common case), and what kind of a program would he write?
The same programmer would create a much more stable program in Ada.
Ada allows you nearly all the freedom of C++, with a lot more cool stuff beside, without you having to worry about many things that you will have to in C++.
Ada saves you a lot of the trouble that C++ programs suffer from.
Oh, and BTW, the only Ada implementation that has a garbage collection (AFAIK) is the JVM one.
Ada catches way more errors at compile time than most other languages.
It also has quite a bit of runtime checks to make sure that nothing nasty happens.
In that, it's much like Java.
However, usually, if an Ada program compiles, the only bugs it has are logical ones.
I would say that Ada programs are more stable than C++ programs because of this.
And yes, great programmers can create C++ programs that are just as stable as the average Ada program.
The difference IMO is that an *average* Ada programmer can create programs much more stable than another programmer of the same level, that is working with C++.
And yes, there is a kernel in Ada, it's called AdaOS (http://www.adaos.org/)
Who the *hell* is talking about writing a kernel using Perl?
As for C#, as a matter of fact, there *are* people trying to build a kernel using C#.
And for more robust than C++, that isn't very hard.
To mention *the* one language that I think should be used for kernel programming, Ada.
It's *way* more stable than C++, has the same plexibility, and if you are satisfied with the stability of your code, you can supress any/all of the checks that you want.
I think that if you need to use different language to break the task to small parts, then you might want to review your design methods.
You are supposed to do it anyway, after all.
Unless you tend to make the mistakes in the calling code.
I did, and spent a couple of hours trying to find out what is wrong, because I knew what I *meant* to put in the calling code, and never tried to look up what I actually wrote.
First, I think that a developer needs to know several languages, both LLL and HLL.
Now, I think that it's prefferable to do a project in one language, that way it's much easier to mention, and you don't have to move from one way of thinking to the other.
That said, there are some inherited weeknesses and strengths to languages, which is why I think that sometime it's important to mix languages. (For example, creating a fortran library to do the number crunching, or c dll for string handling)
When I mix languages, I usually end up in writing roughly 90% of the application in one language, and using another just to support its weak points (VB for major string handling, frex.)