I think it's much more difficult to crash GDI in NT than it is in consumer versions of Windows. Well, from my experience, it's very hard to crash NT compared to win9x.
And the only troll on this thread was Alex Belits who seems to understand nothing about COM. I suppose it's like showing a cave man a hunter's rifile, he'll still try to use it as a club - or go back to using his own club.
I suspect you could do something like that with Interix. Unfortunately, writing your own subsystem for NT would prolly require licensing stuff from Microsoft |;
Adding users remotely is difficult cause user manager isn't part of MMC in NT4 (it is in W2K). And there is no telnet server.
You would need to really find a telnet server and download the windows NT4 resource kit - free version can be found here That should come with a "shutdown" tool. Incendentally, the windows API to shutdown the machine is ExitWindows and ExitWindowsEx if you're interested:). That's why I like W2K so much, terminal services ROCK. So fast over a 28.8k connection.
I think NT the kernel can run Unix nicely if you write a subsystem for it. I've never personally tried Interix (not Microsoft Interix) but it has X11R5 (old i know) support, bash, gnu tools etc. So something must be unixy about it.
COM is something that Microsoft has been dreaming of for years. Microsoft has always wanted to just make everything object oriented. Why make just the end user experience easy when you can make the programming experience easy too! And I don't think the can really achieve it *without* using it. Eventually they'll learn and COM will get better. That said, I think both COM and IIS work *ok* together. COM is what allows ASP to work at all after all. Remember in IIS you can set web applications to run out of process:).
COM (because most objects are inprocess) indeed do cause problems. Like say, running an ASP page that creates a COM object that goes and blasts the process's memory would be very bad for IIS:). But then, that's what Transaction server is for;).
Yes, maybe hack was too harsh a word. Unix has evolved for a long time, but during that time (esp he 80s) it has been fragmented and thrown around a bit that it seems pretty hackish...to me anyway:). I think Linux is pretty hackish - especially some of the work that's being done now.
The remote management capabilities of NT out of the Box is indeed bad. There are 3rd party tools - actually, Microsoft have one called SMS. And Windows 2000 has basically eliminated this flaw with the inclusion of a telnet server, terminal services, new management console and included windows scripting host & engine. I don't think any of these are 'hacks' with the exception of terminal services, which works pretty well for a hack if you ask me:)~.
I suggest you have a look at windows scripting. Adding 1000 users with a generated password isn't that difficult once you do. Note that you could 'hack' something up with an old batch file, the "net user" command and a small c program to do the rest. NT4 does indeed have very ugly tools for user management and OS management as a whole. They were very simplistic. But there are some pretty neat command line tools (net being one), and the resource kit comes with 300 or so other ones (including a unix like adduser). I reckon NT4 is quite hard to adminster in the enterprise without 3rd party tools, unless you went out and either learnt windows scripting, or went and learnt C++/Win32 programming:). However, where NT4 is mostly used (small businesses with less than 100 people) the simple tools are 'good enuff'.
As for ActiveX and COM. ActiveX and COM should be as much a part of Windows as Perl is to Linux (side note - new version of ActivePerl for windows got released on friday with support for SOAP:D~~). It's a feature, it's not 'embedded' into the kernel or anything, it's just another service provided by the OS (like console and graphics services - or even like pipes, processes and sockets). Security is indeed an issue for COM, but most COM objects aren't registered to be available over the internet (eg. registered as DCOM servers). And security on COM objects by design is very good like the rest of NT. What I mean by this is very fine grain security (more so than Linux). There are definitely problems with this. Complexity of such an 'advanced' security model, and security holes through bugs.
IE is in the kernel. COM is in the kernel. Office is in the kernel. Age Of Empires 2 is in the kernel. NTOS and GUI client are one exe. NT is actually a fat ActiveX control running inside IE.
See, whenever you can't explain why something microsoft makes is fast and works well, you make excuses. Hey, microsoft shoved it in the kernel! microsoft makes secret calls to MakeThisFast** APIs.
COM is NOT in the kernel. It is part of the Windows Operating system. It is implemented using Win32 APIs. And can be reimplemented by anyone else (I know a 3rd year computer science student who in his project basically rewrote the basics of COM). COM is also not windows specific, it can be implemented on a variety of platforms, using what IPC and various APIs are available (ahh abstraction).
NT is made up of very small components all fitting together to make a huge OS that does a lot of stuff. NT has a kernel, it has drivers, it has cool subsystems (that's how NT can also *be* Unix, and can also *be* OS/2). NT is a very clean nice OS implementation. The GDI (graphics stuff) boots up after the kernel, then the real GUI client (i presume you mean explorer) is just a windows application (you don't even need to &*#@$# use explorer). I guess you were joking about that last comment about NT being one exe, but with all the stupid comments i've read on this thread, I can never be sure.
Just read your message again, and it's so misinformed that I have to take another go at explaining this to you.
There is no equivalent in your Windows world because in Windows window system (irony!) is poorly developed, and users need to make shared libraries to do the work that is already done in X by window system and window manager.
Like I've already pointed out, windows has MORE inbuilt ways to IPC than Unix. Your comment about having to use shared libraries to do everything the window system and window manager already does is so absolutely totally wrong. In Windows, you can do everything you describe is done here by X (namely communication with applications, and launching apps(!!!!WTF ofcourse you can do that)). COM is not about doing stuff X does, it's about reusing stuff that a 3rd part (or you have previously) done in a binary way - but dynamically, without relinking code.
Windows offers a way of abstracting access to functions, that are dynamically loaded from DLLs. It's not about having to use DLLs to do work (which is already done), it's about using DLLs to REUSE work already done by someone else in your own project. Adding HTML support to your application by using any webbrowser that implements the IWebBrowser interface forexample. You were totally wrong when you talked about using shared libraries to do already done work. I have to stress that out. It's out REUSING work that has already been done. But it's more than that, it's about being able to have a standard way of naming functions and exporting interfaces to ANY language. That's why COM is supported in so many languages, it's broad and abstract enough to do that. There are many instances where opening up..say a webbrowser in a new window is inappropriate. How would you feel if applets couldn't be embedded into HTML, but ran in their own window? or if images had to have their own window? Or if buttons each had their own window/frame? That's NOT the way to do things.
And that's not all COM is about, OLE is only one implementation of COM. There's the side of COM which is purely about creating reusable 'objects' that are language and cross platform (not in the JVM sense). COM is a simple but exceedingly powerful mechanism that is so ubiqutous on windows now that windows applications are so 'compatible' with each other compared to applications on any other OS.
Your main statements of Windows apps not be able to launch apps, create windows or communicate between applications and having to use DLLs to redo work already done is so absolutely WRONG. I HAVE TO MAKE SURE YOU ARE CLEAR ON THAT. It's something that will be keeping me up at night to know there's someone outthere that is so misinformed.
Run it in a Window? WTF? Controls DO HAVE THEIR OWN WINDOW. But the window is embedded in another window as a control (or widget for unix guys). There is an equivalent of pipes in Windows? ROFL wotever, windows has so many ways of IPC: COM, Pipes, Named Pipes, Sockets, MailSlots, MSMessageQueue, Window Messages, MemoryMappedFiles, ATOMs. NT is a DESIGNED os, and was not 'evolved' like unix and 'hacked' together over time. Yes it's true, unix is hacked. Unix is a powerful hack, but it's still a hack.
Don't you realise that OLE uses pipes/sockets (window messages) etc whenever appropriate, windows uses base windows IPC mechanisms to facilitate things like thread marshaling. But the point is BEING ABLE TO ACCESS THE INTERFACES of components you add.
going
IMediaPlayer->Play();
sure beats the ass of creating a socket, designing a protocol for messagening, reading, writing, reading, writing and all that crap.
You're attitude towards easy of programming and reusability is very disturbing. I presume you don't use any standard C libraries cause you always write your own. I mean, C allows you to write your own functions! And the windows system (irony!) is poorly designed so that you have to use standard c libraries to do anything!
Anyway, using libraries is NOT a flaw, it's an advantage, cross process communication is slow and blows. I suppose in C you would prefer running writing little binaries to do all sorts of functions and communicate to them with pipes rather than just importing existing C functions to do the same functions!
s an example embedding one object in another (eg. spreadsheet in wordprocessor document or wordprocessor document in a web browser)
Not a waste of time if you want to add webbrowser capabilities to your application without writing your own. Not if you want to add a video clip into your powerpoint application.
And I don't see what you mean about spread sheet scrollbards & wp view scaling. They're all available. Word is after all basically an ActiveX server sitting inside a main window frame. Just cause it happens to sit inside IE inside Excel inside PowerPoint doesn't change much. With OLE, there's definitions for ActiveX documents and such, where the menus of collaborating applications are 'joined' together to make one big menu bar at the top. Notice how when you add an excel sheet to word and you click on the sheet, the menu bars and toolbars change?
Anyway, you don't lose functionality (especially if the objects are written propertly). One example of what I've been doing is using Media Player 6, and embedding it into my own J++ based application so I can play MP3 and WMA files from my application.
And I think activex scripting is an excellent example of how good COM can be. I'm sure a few users out there would feel quite comfortable writing ASP or Windows Scripts, it's nothing beyond JavaScript for HTML pages (in fact it's practically the same thing in a different context) which many people now days have at least tried.
I could write a 10 line script to list processes (without running pmon). I call COM objets from javascript (or perlscript) and I get REAL results back, an int when i want to know the PID etc.
BTW, I'm not sure what you mean by embedding objects doesn't include functionality!!! That's the whole point. Sure, if you embedd a mundane object that does nothing, it doesn't do anything. But most people go and embed useful things! Like in wordpad, you might want to embedd a picture....no problem, use the windows defacto standard - OLE and embed paintbrush into your wordpad document.
Usability is also very much improved (imagine doing the inserting images into a document like i described above without OLE - or basically, drag and drop of objects!). OLE is the kind of thing which allows Explorer (with it's HTML integration) to preview video files in a tiny Video Box on the left of your explorer pane (which itself is just MediaPlayer hosted), or preview other things, like HTML documents, powerpoint slides(!) and pictures.
I suppose it's really something you have to try out a lot to appreciate it. You only miss it when it's missing. Look how bad embedding is on Unix. If I want to embed a GIMP image (not just as a bitmap, but as a GIMP object that I can touch up and redraw by double clicking on it...eg. Gimp is hosted) into my text document in KEdit, I can't do it! Remember, for many windows applications, even Buttons and scrollbars are themselves OLE controls (not all, but many).
I believe MS's implementation is EXTREMELY productive, and has led to the easy of programming some pretty advanced stuff in windows. So many apps now have webbrowser capabilities thanks to COM (WinAMP, NeoPlanet, HTMLHelp, etc).
The ability to be able to extend explorer (the windows shell) to the extent which it's capable of could really only be done this efficiently and this reliably (for something that complicated) with something similar to COM (IMHO).
Yes, COM uses DLLs (.so in unix). However, there's more to COM than just calling exported functions:). I should have made that a bit clearer sorry.
The who idea behind com is abstraction thru interfaces (or on reality, just a table of function pointers). Because of this level of abstraction, you can like aquire a function pointer, but it won't neccessearily point to the real function (which you can do in COM) it might point to a proxy or marshall that will send the call off over RPC to the destination object on a remote machine.
Shared Libraries have no concepts of "interfaces" or "classes", and shared libraries generally is a 'c' thing. COM also has relatively strict guidlines on datatypes (BSTR, long, short etc). So any COM aware application will be able to read a string that's passed out from any COM object written by any COM compatible language.
Yes, this sounds a lot like just a specification, and you could implement this on Unix with.so. Writing a simple COM engine would be pretty simple, but writing all the support interfaces, functions libraries, and designing the spec to "work" well in real life (it took COM 10 years of evolution to become to what it is today) is hard. I mean, I like to think of myself as having a better than average understanding of COM for someone who uses COM. But I'm sometimes suprised when I come across *yet another* Co* function that does more stuff. Some simple examples of support functions are object creation (CoCreateInstance), interface querying (QueryInterface), string allocation (Sys* functions), memory allocation (CoMem* functions), hell even some of the default implementations of DLLRegister server for registring CLASS and INTERFACE GUIDs needs a bit of thought. You need a registry to start off with (something Windows has had since win31, and Netscape have implemented for Mozilla's xpCOM).
BTW, sorry about the ugly formatting of the previous post, had HTML formatting on by default (doh).
I was also surprised at how long it was taking *nix developers to create significant component based applications especially since most of COM (at least originally) was copied from or inspired by CORBA.
No DCOM was inspired by CORBA. COM is quite different from CORBA in many ways, and was inspired by all sorts of technologies that arose from microsoft in the early 90s (VBX etc). Also, you have to remember that many things that developed from COM, but non the less are so important to windows nowdays (like OLE) are not specified in some standard way w.r.t CORBA. Microsoft has also been talking about component models and powerful scripting (ala Office) since the mid 80s.
In Unix COM wasn't necessary? LOL. Well maybe. Just like it's prolly not neccesary to have computers to type up letters (what are pen & paper or typewriters for?). The point is it is FASTER and more EFFICIENT to use compoenent based models like COM. With COM you're basically calling functions to do stuff for you and you're working at a 'lower' level than piping output into new processes which in turn go and do their own bloated stuff. It's MUCH slower. With COM, you can reuse components. You can export a function that dials up the internet by creating the object, aquireing the interface pointer and function pointer then calling it. With ActiveX Scripting languages or programming languages like VB/C++ATL/J++ it's easy. With Unix, you'd create a new process to that involves chat pppd etc etc...all bloated stuff. You're creating a new process, you're running applications and then parsing the output as strings into something meaningful. Why do you think Unix lacks so much of the advanced UI modularity (Controls anyone?) componentization, IPC, interapp interoperability etc that Windows had? Cause it's hard. Cause there's no standard way to do things. Explain to me how I'll be able to copy an image into a clipboard from Gimp and then paste it into XPaint. Or howabout formatted HTML from netscape and then paste it (still formatted - including images and applets) into KEdit. You can't. There's no good mechanism, and usually what mechanism there are aren't standard. Windows has standards for clipboards, for IPC, for component sharing etc. They're defacto windows standards, but that's so much better than no standards at all. With ActiveX scripting languaes, Microsoft have basically created a scripting language that acts very much like the way javascript works in browsers. You've got a COMPONENT based scripting language (you create and call objects), unlike unix where you execute programs and parse their output (ugh). Ofcourse there's 'nice' languages like Perl which offer neat packages, but then, can I use Perl packages easily from TCL? No. In Windows, I can use any ActiveX Scripting language to script, because Microsoft's technologies are all componentised and 'reuse' on each other. As an example, ASP (Active Server Pages) uses ActiveX scripting, so I can script ASP pages with VBScript, JavaScript for PerlScript (or any other activex scripting language someone might write in the future). I can also use VBScript, JavaScript and PerlScript to write scripts in HTML files, or Windows Scripting files. Different languages, same object model. The kit to both write ActiveX Scripting languages of your own, and also implement the engine in your own applications is ofcourse free. There's also other key features of COM which make building HUGE operating systems like Windows 2000 and Office possible. Abstraction through COM interfaces. Microsoft can define some interfaces you have to implement if you want to, for example, add a shell extension tha adds a new Start->Search->Process menu on the start menu. All you need to do is create a COM object that implements those interfaces and register them in the right place in the registry and explorer will find them and add the menu dynamically for you. These same 'abstraction' ideas are used for ActiveX controls, Explorer Bands etc etc etc. That's how that guy managed to create an implmentation of Mozilla that would work in applications that 'embedd' internet explorer. You just go and implement the IWebBrowser interface! Oh well, enough rant. Final word. COMponentization is GOOD and needed for any large style OS or application. Especially if it involves user interfaces or you are concerned about binary reusability (not simply running small tools and parsing output).
How'd you know that? Do you have the source? I'd like to see it. I heard somewhere that the NT BSD stack was based on Linux (and very crappy)...until those benchmarks came along, and even Linus had to conceed.
Oh deary me.
Everything is based on something else...no doubt there are some (ex)BSD developers working at Microsoft.
Having to hold your hand over the keyboard all the time prolly isn't good. With 2 mouse buttons (or 5 on the wheel mice) you can basically sit there with food in one hand and mouse in the other:P
Right clicking inconsistant on windows???? How so? Right clicking always brings up the context menu where there's one applicable. Almost all applications follow the same rulez, the ones that don't are usually games, where context menus don't apply, and the 2nd mouse button is more useful doing something else.
And 2 mouse buttons causing RSI? I *could* believe that. But what's the ramafications of having to move your other hand around to the control key to do a context menu click huh?
That article said that W2K was up for only 7 days. What a load of crap. There was no proof of that, they just stuck it in. I've had W2K servers up for over 4 months (and counting).
Saying windows 2000 stays up for only 7 days is ridiculus, and obviously FUD - and I'll take it as that until I see any proof it's true.
What's wrong with that? It's not like all the APIs, command line and Scripting features are *GONE*.
Just cause there's an easy way to do everything from the GUI now, doesn't mean you can't do it programmitically, scriptically or using command line tools.
Slashdot Mirror
heh :)
I think it's much more difficult to crash GDI in NT than it is in consumer versions of Windows. Well, from my experience, it's very hard to crash NT compared to win9x.
And the only troll on this thread was Alex Belits who seems to understand nothing about COM. I suppose it's like showing a cave man a hunter's rifile, he'll still try to use it as a club - or go back to using his own club.
I suspect you could do something like that with Interix. Unfortunately, writing your own subsystem for NT would prolly require licensing stuff from Microsoft |;
Ok,
What should I do access the DOM inside netscape as I would have if I were a javascript inside netscape?
Can I access the netscape DOM and say change the size of a table, or the background colour of a cell dynamically?
COM makes REUSING objects almost as easy as calling a class. What you're suggesting is horrific.
Windows has had this since Win31 :), but yes, no doubt some other people had this before.
;).
it was called OLE back then.
Evolution of COM.
DDE -> OLE -> COM/DCOM -> OLE2/ActiveX (based on COM) -> COM+
or something like that
Yes it is something unix is struggeling to do still.
You're such an idiot.
What has the fact that X supports windows inside windows got to do with anything I said?
It's like saying that C is useless cause there's already a programming language called ASM.
Try getting a clue.
Adding users remotely is difficult cause user manager isn't part of MMC in NT4 (it is in W2K). And there is no telnet server.
:). That's why I like W2K so much, terminal services ROCK. So fast over a 28.8k connection.
You would need to really find a telnet server and download the windows NT4 resource kit - free version can be found here
That should come with a "shutdown" tool. Incendentally, the windows API to shutdown the machine is ExitWindows and ExitWindowsEx if you're interested
I think NT the kernel can run Unix nicely if you write a subsystem for it. I've never personally tried Interix (not Microsoft Interix) but it has X11R5 (old i know) support, bash, gnu tools etc. So something must be unixy about it.
:).
:). ;).
COM is something that Microsoft has been dreaming of for years. Microsoft has always wanted to just make everything object oriented. Why make just the end user experience easy when you can make the programming experience easy too! And I don't think the can really achieve it *without* using it. Eventually they'll learn and COM will get better.
That said, I think both COM and IIS work *ok* together. COM is what allows ASP to work at all after all. Remember in IIS you can set web applications to run out of process
COM (because most objects are inprocess) indeed do cause problems. Like say, running an ASP page that creates a COM object that goes and blasts the process's memory would be very bad for IIS
But then, that's what Transaction server is for
Thanks for the complement about the text.
...to me anyway :). I think Linux is pretty hackish - especially some of the work that's being done now.
:)~.
:).
:D~~). It's a feature, it's not 'embedded' into the kernel or anything, it's just another service provided by the OS (like console and graphics services - or even like pipes, processes and sockets).
Yes, maybe hack was too harsh a word. Unix has evolved for a long time, but during that time (esp he 80s) it has been fragmented and thrown around a bit that it seems pretty hackish
The remote management capabilities of NT out of the Box is indeed bad. There are 3rd party tools - actually, Microsoft have one called SMS. And Windows 2000 has basically eliminated this flaw with the inclusion of a telnet server, terminal services, new management console and included windows scripting host & engine. I don't think any of these are 'hacks' with the exception of terminal services, which works pretty well for a hack if you ask me
I suggest you have a look at windows scripting. Adding 1000 users with a generated password isn't that difficult once you do. Note that you could 'hack' something up with an old batch file, the "net user" command and a small c program to do the rest.
NT4 does indeed have very ugly tools for user management and OS management as a whole. They were very simplistic. But there are some pretty neat command line tools (net being one), and the resource kit comes with 300 or so other ones (including a unix like adduser).
I reckon NT4 is quite hard to adminster in the enterprise without 3rd party tools, unless you went out and either learnt windows scripting, or went and learnt C++/Win32 programming
However, where NT4 is mostly used (small businesses with less than 100 people) the simple tools are 'good enuff'.
As for ActiveX and COM. ActiveX and COM should be as much a part of Windows as Perl is to Linux (side note - new version of ActivePerl for windows got released on friday with support for SOAP
Security is indeed an issue for COM, but most COM objects aren't registered to be available over the internet (eg. registered as DCOM servers). And security on COM objects by design is very good like the rest of NT. What I mean by this is very fine grain security (more so than Linux). There are definitely problems with this. Complexity of such an 'advanced' security model, and security holes through bugs.
Thanks,
I might well do that. I think it'd be better for my health too. The frustration with talking with idiots is getting to me.
Myths that keep popping up.
IE is in the kernel.
COM is in the kernel.
Office is in the kernel.
Age Of Empires 2 is in the kernel.
NTOS and GUI client are one exe.
NT is actually a fat ActiveX control running inside IE.
See, whenever you can't explain why something microsoft makes is fast and works well, you make excuses. Hey, microsoft shoved it in the kernel! microsoft makes secret calls to MakeThisFast** APIs.
COM is NOT in the kernel. It is part of the Windows Operating system. It is implemented using Win32 APIs. And can be reimplemented by anyone else (I know a 3rd year computer science student who in his project basically rewrote the basics of COM). COM is also not windows specific, it can be implemented on a variety of platforms, using what IPC and various APIs are available (ahh abstraction).
NT is made up of very small components all fitting together to make a huge OS that does a lot of stuff. NT has a kernel, it has drivers, it has cool subsystems (that's how NT can also *be* Unix, and can also *be* OS/2). NT is a very clean nice OS implementation. The GDI (graphics stuff) boots up after the kernel, then the real GUI client (i presume you mean explorer) is just a windows application (you don't even need to &*#@$# use explorer).
I guess you were joking about that last comment about NT being one exe, but with all the stupid comments i've read on this thread, I can never be sure.
Just read your message again, and it's so misinformed that I have to take another go at explaining this to you.
..say a webbrowser in a new window is inappropriate. How would you feel if applets couldn't be embedded into HTML, but ran in their own window? or if images had to have their own window? Or if buttons each had their own window/frame? That's NOT the way to do things.
There is no equivalent in your Windows world because in Windows window system (irony!) is poorly developed, and users need to make shared libraries to do the work that is already done in X by window system and window manager.
Like I've already pointed out, windows has MORE inbuilt ways to IPC than Unix. Your comment about having to use shared libraries to do everything the window system and window manager already does is so absolutely totally wrong. In Windows, you can do everything you describe is done here by X (namely communication with applications, and launching apps(!!!!WTF ofcourse you can do that)). COM is not about doing stuff X does, it's about reusing stuff that a 3rd part (or you have previously) done in a binary way - but dynamically, without relinking code.
Windows offers a way of abstracting access to functions, that are dynamically loaded from DLLs. It's not about having to use DLLs to do work (which is already done), it's about using DLLs to REUSE work already done by someone else in your own project. Adding HTML support to your application by using any webbrowser that implements the IWebBrowser interface forexample. You were totally wrong when you talked about using shared libraries to do already done work. I have to stress that out. It's out REUSING work that has already been done. But it's more than that, it's about being able to have a standard way of naming functions and exporting interfaces to ANY language. That's why COM is supported in so many languages, it's broad and abstract enough to do that. There are many instances where opening up
And that's not all COM is about, OLE is only one implementation of COM. There's the side of COM which is purely about creating reusable 'objects' that are language and cross platform (not in the JVM sense). COM is a simple but exceedingly powerful mechanism that is so ubiqutous on windows now that windows applications are so 'compatible' with each other compared to applications on any other OS.
Your main statements of Windows apps not be able to launch apps, create windows or communicate between applications and having to use DLLs to redo work already done is so absolutely WRONG. I HAVE TO MAKE SURE YOU ARE CLEAR ON THAT. It's something that will be keeping me up at night to know there's someone outthere that is so misinformed.
*groan*
you don't know what you're talking about.
Run it in a Window? WTF? Controls DO HAVE THEIR OWN WINDOW. But the window is embedded in another window as a control (or widget for unix guys).
There is an equivalent of pipes in Windows? ROFL wotever, windows has so many ways of IPC: COM, Pipes, Named Pipes, Sockets, MailSlots, MSMessageQueue, Window Messages, MemoryMappedFiles, ATOMs. NT is a DESIGNED os, and was not 'evolved' like unix and 'hacked' together over time. Yes it's true, unix is hacked. Unix is a powerful hack, but it's still a hack.
Don't you realise that OLE uses pipes/sockets (window messages) etc whenever appropriate, windows uses base windows IPC mechanisms to facilitate things like thread marshaling. But the point is BEING ABLE TO ACCESS THE INTERFACES of components you add.
going
IMediaPlayer->Play();
sure beats the ass of creating a socket, designing a protocol for messagening, reading, writing, reading, writing and all that crap.
You're attitude towards easy of programming and reusability is very disturbing. I presume you don't use any standard C libraries cause you always write your own. I mean, C allows you to write your own functions! And the windows system (irony!) is poorly designed so that you have to use standard c libraries to do anything!
Anyway, using libraries is NOT a flaw, it's an advantage, cross process communication is slow and blows. I suppose in C you would prefer running writing little binaries to do all sorts of functions and communicate to them with pipes rather than just importing existing C functions to do the same functions!
s an example embedding one object in another (eg. spreadsheet in wordprocessor document or wordprocessor document in a web browser)
Not a waste of time if you want to add webbrowser capabilities to your application without writing your own. Not if you want to add a video clip into your powerpoint application.
And I don't see what you mean about spread sheet scrollbards & wp view scaling. They're all available. Word is after all basically an ActiveX server sitting inside a main window frame. Just cause it happens to sit inside IE inside Excel inside PowerPoint doesn't change much. With OLE, there's definitions for ActiveX documents and such, where the menus of collaborating applications are 'joined' together to make one big menu bar at the top.
Notice how when you add an excel sheet to word and you click on the sheet, the menu bars and toolbars change?
Anyway, you don't lose functionality (especially if the objects are written propertly).
One example of what I've been doing is using Media Player 6, and embedding it into my own J++ based application so I can play MP3 and WMA files from my application.
And I think activex scripting is an excellent example of how good COM can be. I'm sure a few users out there would feel quite comfortable writing ASP or Windows Scripts, it's nothing beyond JavaScript for HTML pages (in fact it's practically the same thing in a different context) which many people now days have at least tried.
I could write a 10 line script to list processes (without running pmon). I call COM objets from javascript (or perlscript) and I get REAL results back, an int when i want to know the PID etc.
BTW, I'm not sure what you mean by embedding objects doesn't include functionality!!! That's the whole point. Sure, if you embedd a mundane object that does nothing, it doesn't do anything. But most people go and embed useful things! Like in wordpad, you might want to embedd a picture....no problem, use the windows defacto standard - OLE and embed paintbrush into your wordpad document.
Usability is also very much improved (imagine doing the inserting images into a document like i described above without OLE - or basically, drag and drop of objects!). OLE is the kind of thing which allows Explorer (with it's HTML integration) to preview video files in a tiny Video Box on the left of your explorer pane (which itself is just MediaPlayer hosted), or preview other things, like HTML documents, powerpoint slides(!) and pictures.
I suppose it's really something you have to try out a lot to appreciate it. You only miss it when it's missing.
Look how bad embedding is on Unix. If I want to embed a GIMP image (not just as a bitmap, but as a GIMP object that I can touch up and redraw by double clicking on it...eg. Gimp is hosted) into my text document in KEdit, I can't do it!
Remember, for many windows applications, even Buttons and scrollbars are themselves OLE controls (not all, but many).
I believe MS's implementation is EXTREMELY productive, and has led to the easy of programming some pretty advanced stuff in windows. So many apps now have webbrowser capabilities thanks to COM (WinAMP, NeoPlanet, HTMLHelp, etc).
The ability to be able to extend explorer (the windows shell) to the extent which it's capable of could really only be done this efficiently and this reliably (for something that complicated) with something similar to COM (IMHO).
Yes, COM uses DLLs (.so in unix). However, there's more to COM than just calling exported functions :). I should have made that a bit clearer sorry.
.so. Writing a simple COM engine would be pretty simple, but writing all the support interfaces, functions libraries, and designing the spec to "work" well in real life (it took COM 10 years of evolution to become to what it is today) is hard.
The who idea behind com is abstraction thru interfaces (or on reality, just a table of function pointers). Because of this level of abstraction, you can like aquire a function pointer, but it won't neccessearily point to the real function (which you can do in COM) it might point to a proxy or marshall that will send the call off over RPC to the destination object on a remote machine.
Shared Libraries have no concepts of "interfaces" or "classes", and shared libraries generally is a 'c' thing. COM also has relatively strict guidlines on datatypes (BSTR, long, short etc). So any COM aware application will be able to read a string that's passed out from any COM object written by any COM compatible language.
Yes, this sounds a lot like just a specification, and you could implement this on Unix with
I mean, I like to think of myself as having a better than average understanding of COM for someone who uses COM. But I'm sometimes suprised when I come across *yet another* Co* function that does more stuff. Some simple examples of support functions are object creation (CoCreateInstance), interface querying (QueryInterface), string allocation (Sys* functions), memory allocation (CoMem* functions), hell even some of the default implementations of DLLRegister server for registring CLASS and INTERFACE GUIDs needs a bit of thought. You need a registry to start off with (something Windows has had since win31, and Netscape have implemented for Mozilla's xpCOM).
BTW, sorry about the ugly formatting of the previous post, had HTML formatting on by default (doh).
I was also surprised at how long it was taking *nix developers to create significant component based applications especially since most of COM (at least originally) was copied from or inspired by CORBA.
No DCOM was inspired by CORBA. COM is quite different from CORBA in many ways, and was inspired by all sorts of technologies that arose from microsoft in the early 90s (VBX etc). Also, you have to remember that many things that developed from COM, but non the less are so important to windows nowdays (like OLE) are not specified in some standard way w.r.t CORBA. Microsoft has also been talking about component models and powerful scripting (ala Office) since the mid 80s.
In Unix COM wasn't necessary? LOL. Well maybe. Just like it's prolly not neccesary to have computers to type up letters (what are pen & paper or typewriters for?). The point is it is FASTER and more EFFICIENT to use compoenent based models like COM. With COM you're basically calling functions to do stuff for you and you're working at a 'lower' level than piping output into new processes which in turn go and do their own bloated stuff. It's MUCH slower. With COM, you can reuse components. You can export a function that dials up the internet by creating the object, aquireing the interface pointer and function pointer then calling it. With ActiveX Scripting languages or programming languages like VB/C++ATL/J++ it's easy. With Unix, you'd create a new process to that involves chat pppd etc etc...all bloated stuff. You're creating a new process, you're running applications and then parsing the output as strings into something meaningful. Why do you think Unix lacks so much of the advanced UI modularity (Controls anyone?) componentization, IPC, interapp interoperability etc that Windows had? Cause it's hard. Cause there's no standard way to do things. Explain to me how I'll be able to copy an image into a clipboard from Gimp and then paste it into XPaint. Or howabout formatted HTML from netscape and then paste it (still formatted - including images and applets) into KEdit. You can't. There's no good mechanism, and usually what mechanism there are aren't standard. Windows has standards for clipboards, for IPC, for component sharing etc. They're defacto windows standards, but that's so much better than no standards at all. With ActiveX scripting languaes, Microsoft have basically created a scripting language that acts very much like the way javascript works in browsers. You've got a COMPONENT based scripting language (you create and call objects), unlike unix where you execute programs and parse their output (ugh). Ofcourse there's 'nice' languages like Perl which offer neat packages, but then, can I use Perl packages easily from TCL? No. In Windows, I can use any ActiveX Scripting language to script, because Microsoft's technologies are all componentised and 'reuse' on each other. As an example, ASP (Active Server Pages) uses ActiveX scripting, so I can script ASP pages with VBScript, JavaScript for PerlScript (or any other activex scripting language someone might write in the future). I can also use VBScript, JavaScript and PerlScript to write scripts in HTML files, or Windows Scripting files. Different languages, same object model. The kit to both write ActiveX Scripting languages of your own, and also implement the engine in your own applications is ofcourse free. There's also other key features of COM which make building HUGE operating systems like Windows 2000 and Office possible. Abstraction through COM interfaces. Microsoft can define some interfaces you have to implement if you want to, for example, add a shell extension tha adds a new Start->Search->Process menu on the start menu. All you need to do is create a COM object that implements those interfaces and register them in the right place in the registry and explorer will find them and add the menu dynamically for you. These same 'abstraction' ideas are used for ActiveX controls, Explorer Bands etc etc etc. That's how that guy managed to create an implmentation of Mozilla that would work in applications that 'embedd' internet explorer. You just go and implement the IWebBrowser interface! Oh well, enough rant. Final word. COMponentization is GOOD and needed for any large style OS or application. Especially if it involves user interfaces or you are concerned about binary reusability (not simply running small tools and parsing output).
How'd you know that? Do you have the source? I'd like to see it.
I heard somewhere that the NT BSD stack was based on Linux (and very crappy)...until those benchmarks came along, and even Linus had to conceed.
Oh deary me.
Everything is based on something else...no doubt there are some (ex)BSD developers working at Microsoft.
Having to hold your hand over the keyboard all the time prolly isn't good. With 2 mouse buttons (or 5 on the wheel mice) you can basically sit there with food in one hand and mouse in the other :P
Right clicking inconsistant on windows???? How so?
Right clicking always brings up the context menu where there's one applicable. Almost all applications follow the same rulez, the ones that don't are usually games, where context menus don't apply, and the 2nd mouse button is more useful doing something else.
And 2 mouse buttons causing RSI? I *could* believe that. But what's the ramafications of having to move your other hand around to the control key to do a context menu click huh?
Check this impressive demo out..
Paragraph's Demo
Even better, it works on Windows CE HPC and PPC devices natively. (Ofcourse CE fully supports Java 1.1 too).
That article said that W2K was up for only 7 days. What a load of crap. There was no proof of that, they just stuck it in. I've had W2K servers up for over 4 months (and counting).
Saying windows 2000 stays up for only 7 days is ridiculus, and obviously FUD - and I'll take it as that until I see any proof it's true.
Dumbs everything down?
What's wrong with that? It's not like all the APIs, command line and Scripting features are *GONE*.
Just cause there's an easy way to do everything from the GUI now, doesn't mean you can't do it programmitically, scriptically or using command line tools.
I think you a reality check.
You do realise that most drivers that come with windows are written by manufactueres, and then are verified, tested and signed by microsoft.
And it's normally 3rd party drivers that cause system crashes. And I trust you've never even tried Windows 2000?
Cause those aliens from ID4 will be annoyed when the arrive and realise that they can't use our own satellites against us :P.
Guess who OS had the fine grained locks and multithreaded IP stack and kick linux's ass in benchmarks.
NT.