Hello PJ,
I'll reply here first ... I like these posts where we agree more ... ;-)
> There's only one problem I find with MSFT incorporating a browser
> into their OS. If it's part of the OS like MSFT states, integrated
> into their product and platform so much so that by removing it you
> render the OS useless or damaged then why do they distribute a
> version of MSIE, for other platforms such as UNIX and MacIntosh?
> That's not an extension to Windows, it's a stand-alone product.
So if you look at software architectures, it is rare these days that any software application incorporates *all* of the functionality within it's binaries. So yes, it's possible to have the application run on various platforms, but the amount of code it takes will vary on each platform.
Microsoft is a very good example of eating their own dog-food. They have created a programming environment that is based around their own MFC classes, and object model. As the Windows platform has continued to grow, it has added more and more functionality in the core OS (which has bloated the size and processing requirements) but it has also meant that much of the foundation for many applications is already in place on the platform.
The best example of this for the beginner (not saying you) is to look at Visual Basic. Microsoft has done an incredible job with Visual Basic, in exposing a wide range of easy-to-use objects to the Basic programming language. These same objects can be used in C, or C++, or Web applications.
Microsoft took their browser, after several iterations to understand it well, and broke it up into a variety of objects that can be used together or separately. They decided that since many applications might want to use TCP/IP and WinSOCK2 they would provide "wrappers" on these, in their API "flavor" for all applications to use. They decided that since many application might want to display HTML, they would create an object that can render HTML in a window. They decided that since many applications might want to make HTTP or FTP requests, they would create an object which can handle these. This is the same thing they did with Office ... Word, Excel, PowerPoint, etc. all share a bunch of common objects.
As more of the functionality became clear, they began to filter these objects into the core distribution ... the OS and it's components. The parallel to this is Intel adding more and more common processing tasks into the core microprocessor. They are now including extra math functions for graphics processing. The most common, and well known, algorythms are always going to filter down to silicon. Things that Microsoft includes in libraries today will be complimented by silicon in the future.
So when you say it's a "stand-alone" product, you seem to indicate that the source code and binaries are identical across all these platforms that you mention. (Windows, Mac, and UNIX) But this is not the case ... it can't be. There could be some similar code, but there are platform specific modules that must be written. For example, MFC contains most of the code for displaying things like windows, menues, list boxes, pop-up dialogs, buttons, etc. If I were Microsoft I would try to port the required pieces of MFC over to UNIX and the Mac where these platform specific versions would translate the MFC calls into the platform specific APIs to do the same functions. I'm not sure if this is what they have done ... but they sure can't just call a MFC42.DLL to open a window, or pop up a list box.
Like wise, even the APIs to perform TCP/IP communications are much different between the different platforms. UNIX tends to use Sockets programming (which actually is very thread inefficient for large numbers of TCP connections) and I don't know what the Mac uses. But to write IE for these platforms, Microsoft had to recreate platform specific versions of something to enable the HTTP and TCP communications. Tjis doesn't even get into the differences in memory management and thread models between the various OS's ...
IE isn't really stand-alone ... there are numerous versions of it ... probably with *some* shared code. I'd love to get an idea of what percentage since this would then provide good insight to the efficiency of their object model and portability.
> I just don't see how it can be an integral part of Windows and
> still have the ability to stand on its own. To me, they would have
> to say its one or the other.
So the real difference is how much additional code had to be installed on UNIX with the UNIX version ... and likewise for Mac. It's really three products.
> See if I buy that car with the cell phone, do I have a choice to
> say, hey, I don't want that brand of cell phone? Or is my choice
> limited by the vendor. Then I have to take that cell phone in order
> to get the car I want because I don't have a choice.
I would argue that the vendor can choose! He/she should be free to decide what they are going to produce, and he/she should have the freedom to decide if they want to accomodate you as a customer.
I was just looking at a auto-manufacturers page this morning after reading your post. What if I want to buy a car today, that comes standard with anti-lock brakes. Should I be able to say "Oh come on, they aren't 'integrated' into the car ... remove them!" Or the same with power door locks ... or windows ... or tinted windows ... or roof-top luggage rack (who uses those things?) ... and the list goes on.
> Actually that analogy falls short since my only other choice would
> be an operating system that is unfamiliar to me and far less
> practical at this time for me to implement at home. If I had a
> choice of OSs which didn't require me to learn a new interface (yes
> I know about KDE and GNOME), or learn new ways to troubleshoot it
> if and when there was a problem then I wouldn't mind.
But that gets into a dangerous area. I have been looking at Apple iBooks (wow ... another survivor ...) and the one thing that I really dislike is that I feel that many of the UI features that Microsoft provide increase my productivity. The Mac interface seems old and clunky to me. I *love* a two button mouse and use the "right-click" extensively throughout the day (a feature created by Borland?) to increase the rate at which I can perform work. But for whatever reason, Apple refuses to "give the customer the choice" in configuring the UI ... something that Microsoft does do. I don't like active desktop ... and Microsoft let's me disable it ...
These other vendors are making decisions to *not* provide me with what I want ... so I'll stick with a company who does.
> As it stands, MSFT has me locked in so I can only follow along.
I'm not sure ... you said above "If I had a choice of OSs which
didn't require me to learn a new interface" ... and I agree completely! But no intelligent, market-minded company is listening to you or I to provide us what we want! MSFT isn't locking you in ... the Mac, Linux, UNIX, etc. are locking you in by not realizing what we want!
> Here's another question for you and with your expertise, perhaps
> you can teach me about this. Its just something I've always
> wondered about.
I'll try ... ;-)
> If MSFT is so into OpenSource then why don't they agree to work
> with other software companies to create a universal driver model
> whereby any device driver written for a PC (or even a MAC) could be
> used by any program or OS? The real bottleneck in this industry is
> where the hardware meets the software. The Win32 platform has that
> all locked up.
This is actually what I2O (from Intel) is all about. It's more than the software driver, it's the hardware bus interface (not every machine has ISA or PCI today) and the way that these adapters interface at hardware levels.
> If a device company were able to write ONE device driver that would
> work with ANY OS because there was a universal specification
> wouldn't this be a good thing for the computer industry.
Yes! I was actually the original product manager at Novell when we introduced ODI ... the Open Datalink Interface ... the software architecture for LAN drivers. This is still being used in the NetWare server, and I believe somewhat in the NetWare clients. But Microsoft and 3Com had a competing standard ... NDIS. Although there were talks between the two companies no decision was ever made. There were major philosophical differences. MS and 3Com couldn't use ODI because they were so certain that "memory protection" and using the Intel "rings" were necessary. ODI relies on passing pointers for performance and efficiency. Novell wasn't about to use NDIS because it was ridden with memory copies ... the most costly performance error you can make. So the stalemate ... until more recently. Microsoft has punted on much of it's memory protection (at the driver level everything runs at ring 0 due to performance issues ... imagine that ... something Novell knew for years) and PCI bus seems to have standardized in the market. So Intel created I2O which says, "Here is the way that you talk to an adapter ... write one driver and it will work with all adapters of a particular type." Novell supports this fully ... the I2O drivers for NetWare have been shipping for years.
Now it's just time for the cost of the adpaters to come down ... you aren't going to find a $20 I2O Ethernet board right now. (Well ... if you do please let me know! I want a bunch of them! ;-)
> Perhaps I'm just clueless :) At least I'm not emotional day....yet.
Nope ... not clueless ... the devil is in the details ... ;-)
> Peter J Strifas
Scott C. Lemon |
