2. Linux companies do not necessarily make the telnet et al that are bundled. MS makes all of their pieces (i.e. if they had bundled IE, Netscape, maybe Opera, and set it up so that you could choose whichever one you wanted, they wouldn't be accused of bundling)
Actually, MS licences a bunch of peices that are included in the OS. It's normally the utilities and codecs though. One example is the "Imaging" program is from WANG. In win2k the degragmentation software is third party too. Hyperterm is probably the most obvious third party peice. In the case of a web browser, opera wasn't around and netscape refused to make a version that could be embedded in an app the way a key peice needs to be in the windows platform. However it would have been cool if there was some form of api standard for being a web browser, such that anyone could have plugged in. Of course on a testing perspective that would have been a nightmare for anyone writting an app that used it,
The reason companies get the OEM copy is that OEM's charge more for an "unstandard" config then then you actually pay for an MSFT os unless you are doing large bulk orders of machines. See the previous/. discussions on this. Don't blame ms on what OEM chose to offer and how they price it.
There is room here for a company to make money by selling machines blank.
I always thought API meant "Application Programming Interface". Kind of like the public methods of a class in C++. Who knows how I implement helper functions, or what I call. Those aren't part of the "API" they are part of the implementation of the API. The API is the interface, not the internal classes that the interface uses to to get it's job done.
I find that the term API dates back to when you didn't really have all the layers of software that is common today. The Final Judgement definition is loose enough to describe the wire protocol of telnet as an API. However, my working definition is any public interface is an API.
An application should ONLY use APIs, not calls to lower, unpublished levels, unless it wants to risk breaking at the next release of the implementation of the API... However, an agreement to not change a certain call, because it's used by a certain app in another group...
Considering the complexity and costs of maintaining an API, its hard to believe that such a beast has time to exist. Inside a product you can do such things; you can work with the guy down the hall when things don't work and they can fix it. Exposing a private API to a seperate product; you now have different ship cycles, priorities, and its not obvious when the hidden APIs new owner (devs come and go) changes something that they haven't suddently broken another product. The other problem is generally why call a hidden API? If you need some form of functionality that is available, it is more then likly the best way to get to it is the published method. If it is pure code sharing, then great, it is thier right to not share. This is however blanced against the potential cost of denying something useful to the platform's developers (for ex: ATL started as internal code sharing and became a shipping part of visual studio for anyone). Personally, what is and isn't exposed is best left to the people who make it.
Indeed, Be Inc publish their API (with extensive documentation) for interfacing with their Operating System, the BeOS. Open API, close source. As a BeOS programmer, I can say it works fine.
Do you really think Be has ALL of thier APIs open? I seriously doubt it. Any good code will break down an implementation of a public API into smaller peices. These peices each have an API, but they are subject to change, hence they are private. Opening up private API's can only lead to people using them, and these apps would break on almost any reimplementation or change. Not having an app work on the next version of a product is bad thing for buissness and exceptance of the next version of the component.
People using private API's are the ones that break on the next version of the project. If customers really need access to certain types of internal data, as have happend with virus scanners, then the custimer feedback may lead to some clean up work and some private APIs may be come published, or a new API will be created as an abstraction layer. A public API in the commericial world is an expensive thing. The interface may need to be cleaned up code wise, documentation work including sample code, a much higher degree of testing needs to be done, and developer support will have to cover it for as long as the API is on the market (forever). From my perspective the testing is the more expensive part.
Do you regard controlling your hardware the same way?
To an extent yes.
Do I have options for disk formats?
Yes. Unfortunatly the IFSKit for writting filesystems ( as viewed by the os instead of namespaces on the shell ) is not free on MSDN. I believe this is largly due to the greatest customer of the kit is the peopele writing virus dectetion software who have a nasty habit of making the os unstable with thier crappy drivers. Ms doesn't just sell the kit they sell the kit with support time to make sure the things that are released aren't too crappy. Universities can get free access to the IFSKit IIRC.
Do I have only the options of using GDI, Direct X, OpenGL(too good to be abandoned by Microsoft)when accessing Video.
You have whatever the graphics driver writers want to expose to you. Most of them choose between opengl and directx for thier 3d desires. However It seems like every major vendor has there own ism's to thier implementations such that they aren't really compatable. 3dfx opengl versus standard opengl, etc. If you really want to go above and beyond in terms of the GDI you can always write your own stuff (winamp for example looks like they do thier own stuff for the main window, and the old borland widget set had it's own look) These things take effort, effort that tends to be tangential to what the majority of developers want to spend thier time writing code for.
What is best for the consumer is options and in the OS it must deal strickly with functions that deal with the Hardware.
An operating system isn't just about controlling hardware. It is about services to applications to make things happen regardless if that thing has to do directly with the hardware or not, the common services gnome and kde are providing are examples of stuff that should be considered part of the OS if you wish to avoid comparing apples and oranges. You want to strickly talk about abstracting hardware, then we are talking about the kernel and very base system libraries. End users aren't intrested so much in what does the base system libraries look like and even what gui widget sets that come with the os, as much as which applications work, and does thier hardware work. The application devs are intrested in using more shared code. When borland was the thing, their widget sets where commonly used, but since then thier popularity has fallen off. There tends to be a natural process where the new peices have lots of options, but as time progresses only one or two become commonly used, defacto standardization. However no one forces you to use the common peices, you are just as free to make your own. The thing that gets unix people a bit upset is that ms spends it's time writting new peices on windows, instead of porting the existing pieces to other operating systems, which is fine since the same unix devs don't ususally bother porting thier libries back to windows. The few that do get ported to windows are not free and generally don't have as good tools as the ms couterparts, and hence they don't do well. Consumers aren't looking for options inside thier os in the way you are describing, and in many cases thier apps being dependant on a peice that isn't mainstream makes life more difficult for the app writer and hence worse for the end consumer, since it doesn't work with as well as the other peices. When there isn't a mainstream peice the developer has to support things like 3 different ways to do 3d instead of what they are doing with the 3d apis, and the consumer has to worry about if the game they are buying works well with the 3d support thier 3d card marker has chosen. Microsoft has little intrest breaking products that are selling windows, it doesn't make buissness sence. They try to entice devs and custimers to thier libraries/programs via being better peices to use.
Fine, let them integrate IE. That's their right. I like the integration idea. It improves the functionality of the OS. The problem isn't the integration(well, they could have programmed it a little better), the problem is that they should give other companies the same right.
No one has ever taken away other developers/companies rights here. It would have been a much more intresting world if netscape had let go of some of thier cross platform compatability uptightness and given what the app developers wanted from the browser... Access to thier parser and embedability. People are still free to write these things themselves.
I would like to see some other companies develop something that can integrate into the OS like IE does.
Ie is only as integrated as other code uses it. This is why microsoft can do intresting things, One team produces something potentially useful, publishes the interface on msdn and then trys to convince all the developers in the company (and out) to use it. If you can convince upper management that your functionality should be everywhere, then they can push groups to use it. Most ms products now depend on the existance of the html parser as much as they expect the existance of file system. If a third party creates something that everyone uses, ms will try to licence (and in some cases buy) that product for windows. This is why there are a number of third party codecs that ship with the os for example.
That would be competition. Allowing other companies to integrate their own software into Windows should be a must. But they don't allow for a company to do that. It is always a program that runs on top of Windows, never with Windows.
There are plenty of applications that integrate with windows. A virus scanner is a great example. These things hook into file io and network io to scan for viruses on the fly. Another thing would be like oracle's internet file system thingy, where they integrate into the gui shell. Namespace extensions for the shell are great for merging seamlessly into the gui environement.
A disadvantage of closed source is that you can't just copy and modify the existing implementation/framework. You either write to what the framework lets you, or you don't use the framework and write the same functionality yourself. If you want to do more then what the shell allows, then you check msdn and write what you want. You are then reinventing the wheel to a degree but that is the price you pay. Once you have your competing framework you must convince others that it is the way to go. Say you really hate ADO/OLEDB/ODBC as a common way to access databases for some reason. You write your cool nifty cross platform database methodology, and now need to convince people to use it. Soemtimes you win sometimes you don't. The media player "wars" are an example of that. MS has a system of os wide pluggable codecs and generic controls to use thoose codecs. However real media and apple with quicktime are each providing thier own api's for integrating video/sound to developers. It's not clear who will win in this space. I'll bet you that whoever does win will get an offer to have thier technology licensed and shipped with the next windows os release.
Make IE be taken away from the original install of Windows. Let it be an added feature
And instantly break the last 4 years worth of software development.... "Okay we took the html parser out, and now nothing works but the stuff from before '96... geez that sucked."
Taking a few of your paragraphs out of order.... I say that they should be broken up into OS and Software companies. Take IE away from Windows. Let it be an added feature that would integrate into Windows. But most importantly let others be given the same opportunity.
One serious problem with that is if you let people uninstall it, then you have to ship with a version on your third party product's media when you use it. The alternative is that a developer can't expect the functionality to be there, and either has to reinvent the wheel, or just not take advantage of what the shared code could let them do. The newest version of this issue is XML. The gov wants xml parsers to not be supplied by the os company, no matter how useful a shared xml parser would be to the third party developer. However for html ms doesn't just expose a parser, they also expose an control which makes any app that wants to be an html browser with almost infinite control. The actual iexplorer window is that control, a container and support for things like bookmarks, etc. If you are worried about an icon... Icons can be removed. To me this is alot like X widget sets. Different widget sets exist. They largely do the same thing, but don't expose the same interfaces and only one is used by the currently running gui shell.
Does anybody see what MS is asking for? This is the scary part. They want to have the ability to view the code of other companies. Why would they have to ask for permission to do this??? They don't, they would just sign a contract/license agreement with terms that each company would agree to, and that would be that. UNLESS that company is the Application company, and the competitor is the OS company. Anybody think what implications that would have?? I can.
The exact same implications of the other way? I think this is a mild form of humor in thier response. Intellectual property is exactly that. You require that people can see the source fir "compatability", you need to make sure that the actual intellectual property is not being stolen. You have any ideas short of what ms is asking to verify this? On the free software side... you could also think of it as a bizzare twisted version of the GPL, "You see my source, then at least we need to see your source"
My guess is that MS is concenred with thier market share in education markets for the campus wide major computer networks (think IT services). So they want to work on that. I don't think Linux is anything but one of the ton of competitors already there, Novell, Sun, Notes, etc..
The classic development of UNIX in an university setting is a more research focus or students doing an intresting project focus.
It's not even like the mac examples the article pointed out, since must universitys don't officially support linux anyways. A real concern might be if say an exchange server gets installed and the admin for it decides that he doesn't want imap or pop clients to be able to connect, but then that is the admins choice. Even if some sort of incompatability like that came in to being, then someone will sit down and figure out the interface and write code to it.
There has been no change in all the standard office apps formats. (Ms was burned last time they changed them) What is new is the ability to save your document in html in such a way that you can reconstruct the original propritary format documents features. The use of XML is sprinkled around the document to store much of the metadata of the document and to build style sheet like stuff inside the html.
It's not really saving any document in xml, which is what I'd like to see some day.
The biggest problem to this seems to be embedded documents which always use some form of distributed object technology ( like COM, KOM/OpenParts, serialized java objects, etc... ) I guess one would have to convince everyone in the world that there is at least one right way to store these "flattened" or linked objcts which by observation of the number of different methodolgies right now, the technology is still premature.
Slashdot Mirror
Actually, MS licences a bunch of peices that are included in the OS. It's normally the utilities and codecs though. One example is the "Imaging" program is from WANG. In win2k the degragmentation software is third party too. Hyperterm is probably the most obvious third party peice. In the case of a web browser, opera wasn't around and netscape refused to make a version that could be embedded in an app the way a key peice needs to be in the windows platform. However it would have been cool if there was some form of api standard for being a web browser, such that anyone could have plugged in. Of course on a testing perspective that would have been a nightmare for anyone writting an app that used it,
The reason companies get the OEM copy is that OEM's charge more for an "unstandard" config then then you actually pay for an MSFT os unless you are doing large bulk orders of machines. See the previous /. discussions on this. Don't blame ms on what OEM chose to offer and how they price it.
There is room here for a company to make money by selling machines blank.
I find that the term API dates back to when you didn't really have all the layers of software that is common today. The Final Judgement definition is loose enough to describe the wire protocol of telnet as an API. However, my working definition is any public interface is an API.
An application should ONLY use APIs, not calls to lower, unpublished levels, unless it wants to risk breaking at the next release of the implementation of the API... However, an agreement to not change a certain call, because it's used by a certain app in another group...
Considering the complexity and costs of maintaining an API, its hard to believe that such a beast has time to exist. Inside a product you can do such things; you can work with the guy down the hall when things don't work and they can fix it. Exposing a private API to a seperate product; you now have different ship cycles, priorities, and its not obvious when the hidden APIs new owner (devs come and go) changes something that they haven't suddently broken another product. The other problem is generally why call a hidden API? If you need some form of functionality that is available, it is more then likly the best way to get to it is the published method. If it is pure code sharing, then great, it is thier right to not share. This is however blanced against the potential cost of denying something useful to the platform's developers (for ex: ATL started as internal code sharing and became a shipping part of visual studio for anyone). Personally, what is and isn't exposed is best left to the people who make it.
Open API, close source. As a BeOS programmer, I can say it works fine.
Do you really think Be has ALL of thier APIs open? I seriously doubt it. Any good code will break down an implementation of a public API into smaller peices. These peices each have an API, but they are subject to change, hence they are private. Opening up private API's can only lead to people using them, and these apps would break on almost any reimplementation or change. Not having an app work on the next version of a product is bad thing for buissness and exceptance of the next version of the component.
People using private API's are the ones that break on the next version of the project. If customers really need access to certain types of internal data, as have happend with virus scanners, then the custimer feedback may lead to some clean up work and some private APIs may be come published, or a new API will be created as an abstraction layer. A public API in the commericial world is an expensive thing. The interface may need to be cleaned up code wise, documentation work including sample code, a much higher degree of testing needs to be done, and developer support will have to cover it for as long as the API is on the market (forever). From my perspective the testing is the more expensive part.
Do you regard controlling your hardware the same way?
To an extent yes.
Do I have options for disk formats?
Yes. Unfortunatly the IFSKit for writting filesystems ( as viewed by the os instead of namespaces on the shell ) is not free on MSDN. I believe this is largly due to the greatest customer of the kit is the peopele writing virus dectetion software who have a nasty habit of making the os unstable with thier crappy drivers. Ms doesn't just sell the kit they sell the kit with support time to make sure the things that are released aren't too crappy. Universities can get free access to the IFSKit IIRC.
Do I have only the options of using GDI, Direct X, OpenGL(too good to be abandoned by Microsoft)when accessing Video.
You have whatever the graphics driver writers want to expose to you. Most of them choose between opengl and directx for thier 3d desires. However It seems like every major vendor has there own ism's to thier implementations such that they aren't really compatable. 3dfx opengl versus standard opengl, etc. If you really want to go above and beyond in terms of the GDI you can always write your own stuff (winamp for example looks like they do thier own stuff for the main window, and the old borland widget set had it's own look) These things take effort, effort that tends to be tangential to what the majority of developers want to spend thier time writing code for.
What is best for the consumer is options and in the OS it must deal strickly with functions that deal with the Hardware.
An operating system isn't just about controlling hardware. It is about services to applications to make things happen regardless if that thing has to do directly with the hardware or not, the common services gnome and kde are providing are examples of stuff that should be considered part of the OS if you wish to avoid comparing apples and oranges. You want to strickly talk about abstracting hardware, then we are talking about the kernel and very base system libraries. End users aren't intrested so much in what does the base system libraries look like and even what gui widget sets that come with the os, as much as which applications work, and does thier hardware work. The application devs are intrested in using more shared code. When borland was the thing, their widget sets where commonly used, but since then thier popularity has fallen off. There tends to be a natural process where the new peices have lots of options, but as time progresses only one or two become commonly used, defacto standardization. However no one forces you to use the common peices, you are just as free to make your own. The thing that gets unix people a bit upset is that ms spends it's time writting new peices on windows, instead of porting the existing pieces to other operating systems, which is fine since the same unix devs don't ususally bother porting thier libries back to windows. The few that do get ported to windows are not free and generally don't have as good tools as the ms couterparts, and hence they don't do well. Consumers aren't looking for options inside thier os in the way you are describing, and in many cases thier apps being dependant on a peice that isn't mainstream makes life more difficult for the app writer and hence worse for the end consumer, since it doesn't work with as well as the other peices. When there isn't a mainstream peice the developer has to support things like 3 different ways to do 3d instead of what they are doing with the 3d apis, and the consumer has to worry about if the game they are buying works well with the 3d support thier 3d card marker has chosen. Microsoft has little intrest breaking products that are selling windows, it doesn't make buissness sence. They try to entice devs and custimers to thier libraries/programs via being better peices to use.
Fine, let them integrate IE. That's their right. I like the integration idea. It improves the functionality of the OS. The problem isn't the integration(well, they could have programmed it a little better), the problem is that they should give other companies the same right.
No one has ever taken away other developers/companies rights here. It would have been a much more intresting world if netscape had let go of some of thier cross platform compatability uptightness and given what the app developers wanted from the browser... Access to thier parser and embedability. People are still free to write these things themselves.
I would like to see some other companies develop something that can integrate into the OS like IE does.
Ie is only as integrated as other code uses it. This is why microsoft can do intresting things, One team produces something potentially useful, publishes the interface on msdn and then trys to convince all the developers in the company (and out) to use it. If you can convince upper management that your functionality should be everywhere, then they can push groups to use it. Most ms products now depend on the existance of the html parser as much as they expect the existance of file system. If a third party creates something that everyone uses, ms will try to licence (and in some cases buy) that product for windows. This is why there are a number of third party codecs that ship with the os for example.
That would be competition. Allowing other companies to integrate their own software into Windows should be a must. But they don't allow for a company to do that. It is always a program that runs on top of Windows, never with Windows.
There are plenty of applications that integrate with windows. A virus scanner is a great example. These things hook into file io and network io to scan for viruses on the fly. Another thing would be like oracle's internet file system thingy, where they integrate into the gui shell. Namespace extensions for the shell are great for merging seamlessly into the gui environement.
A disadvantage of closed source is that you can't just copy and modify the existing implementation/framework. You either write to what the framework lets you, or you don't use the framework and write the same functionality yourself. If you want to do more then what the shell allows, then you check msdn and write what you want. You are then reinventing the wheel to a degree but that is the price you pay. Once you have your competing framework you must convince others that it is the way to go. Say you really hate ADO/OLEDB/ODBC as a common way to access databases for some reason. You write your cool nifty cross platform database methodology, and now need to convince people to use it. Soemtimes you win sometimes you don't. The media player "wars" are an example of that. MS has a system of os wide pluggable codecs and generic controls to use thoose codecs. However real media and apple with quicktime are each providing thier own api's for integrating video/sound to developers. It's not clear who will win in this space. I'll bet you that whoever does win will get an offer to have thier technology licensed and shipped with the next windows os release.
Make IE be taken away from the original install of Windows. Let it be an added feature
And instantly break the last 4 years worth of software development.... "Okay we took the html parser out, and now nothing works but the stuff from before '96... geez that sucked."
I say that they should be broken up into OS and Software companies. Take IE away from Windows. Let it be an added feature that would integrate into Windows. But most importantly let others be given the same opportunity.
One serious problem with that is if you let people uninstall it, then you have to ship with a version on your third party product's media when you use it. The alternative is that a developer can't expect the functionality to be there, and either has to reinvent the wheel, or just not take advantage of what the shared code could let them do. The newest version of this issue is XML. The gov wants xml parsers to not be supplied by the os company, no matter how useful a shared xml parser would be to the third party developer. However for html ms doesn't just expose a parser, they also expose an control which makes any app that wants to be an html browser with almost infinite control. The actual iexplorer window is that control, a container and support for things like bookmarks, etc. If you are worried about an icon... Icons can be removed. To me this is alot like X widget sets. Different widget sets exist. They largely do the same thing, but don't expose the same interfaces and only one is used by the currently running gui shell.
Does anybody see what MS is asking for? This is the scary part. They want to have the ability to view the code of other companies. Why would they have to ask for permission to do this??? They don't, they would just sign a contract/license agreement with terms that each company would agree to, and that would be that. UNLESS that company is the Application company, and the competitor is the OS company. Anybody think what implications that would have?? I can.
The exact same implications of the other way? I think this is a mild form of humor in thier response. Intellectual property is exactly that. You require that people can see the source fir "compatability", you need to make sure that the actual intellectual property is not being stolen. You have any ideas short of what ms is asking to verify this? On the free software side... you could also think of it as a bizzare twisted version of the GPL, "You see my source, then at least we need to see your source"
My guess is that MS is concenred with thier market share in education markets for the campus wide major computer networks (think IT services). So they want to work on that. I don't think Linux is anything but one of the ton of competitors already there, Novell, Sun, Notes, etc..
The classic development of UNIX in an university setting is a more research focus or students doing an intresting project focus.
It's not even like the mac examples the article pointed out, since must universitys don't officially support linux anyways. A real concern might be if say an exchange server gets installed and the admin for it decides that he doesn't want imap or pop clients to be able to connect, but then that is the admins choice. Even if some sort of incompatability like that came in to being, then someone will sit down and figure out the interface and write code to it.
There has been no change in all the standard office apps formats. (Ms was burned last time they changed them) What is new is the ability to save your document in html in such a way that you can reconstruct the original propritary format documents features. The use of XML is sprinkled around the document to store much of the metadata of the document and to build style sheet like stuff inside the html.
It's not really saving any document in xml, which is what I'd like to see some day.
The biggest problem to this seems to be embedded documents which always use some form of distributed object technology ( like COM, KOM/OpenParts, serialized java objects, etc... ) I guess one would have to convince everyone in the world that there is at least one right way to store these "flattened" or linked objcts which by observation of the number of different methodolgies right now, the technology is still premature.