That is absolutely correct. Any "unification" of Windows is due to the fact that programmers of other toolkits copied the GDI32 and MFC ones. In fact most of the unification on Linux is due to people copying Windows, not from any plan or from copying each other.
Windows programs probably use many times more toolkits than Unix. Except for GTK, ALL the Unix toolkits have a Windows version, plus there are dozens of Windows-only toolkits. Therefore there are more Windows toolkits than Unix. I can confirm that quite a few different ones are being used for Windows programs. Also high-end 3D software and other production software like Avid like to use their own in-house toolkits, so that they can access widgets that don't exist anywhere else.
Yet idiots keep posting here their belief that Windows has a single toolkit and that is why it is "unified". That is FALSE. The reason there is unification is because of toolkits copying each other, something that is finally happening in Linux as well.
True, but IBM was planning the same deal with Digital Research for CPM/86, so they would have ended up in Microsoft's position.
I think whoever ended up in that position (IBM itself if it had done the deals right) would have turned into an evil monopoly. Several would have been far worse than Microsoft is, probably. And Bill Gates would be posting on Slashdot and complaining about the monopoly.
drive letters are primarily provided for backwards compat. They're slowly going away.
Okay, tell me how to open a file on the A: drive without starting it with "A:". And make sure it is a name I can figure out from the normal file browser.
$HOMEDRIVE and $HOMEPATH are both defined on this XP machine.
Okay, tell me how that is compatable with the single environment variable $HOME
you can make files (and other objects) case sensitive if you like; services for UNIX install will do this for you if you so desire.
Not if you want any other programs to be able to read/write them.
Services for UNIX does include many GNU utilities..
Services for Unix is not included by default.
UTF-8 is a poor standard - it's what happens when there's too much legacy tied to ANSI C and C style strings. With UTF-8, strlen no longer means anything:/
strlen() means HOW MANY BYTES ARE IN THE STRING. A VERY useful value. You obvioulsly have ZERO experience with writing any software if you think the number of letters the user sees is a useful value.
UCS-2 from the ground up - a much more reasonable way to do unicode
Read up on "combining characters" before you put your foot in your mouth again. UCS-2 has NO advantages over UTF-8, it's only plausable advantage (fixed-size characters) was obsolete long ago.
I'm not sure why I am dignifying your stuff with a response, but the ignorance here is unbelievable...
Drive letters, ^M^J translation built into the OS, lack of environment variables like $HOME, non-GMT time stamps on the files, inability to handle many punctuation marks in filenames and ISO-8859-1 case-insensitivity and thus the inability to handle UTF-8 correctly in filenames, refusal to provide some GNU tools like a Unix shell...
All of these little details cause us far more grief than the differences in the GUI. And Microsoft could address these easily, eliminating a huge fraction of the hostility that is directed at them. This is what most people are talking about when they say "standards compliant" or whatever.
There is no need for them to provide Linux ABI compatability or even POSIX compatability. What they need to do is to stop ignoring the simple little details where it is obvious to everybody that the Unix design is better. I really think this direct ignorance and disrespect for everybody is the real reason so many hate Microsoft, not because of their closed and monopolistic nature. If NT had been even mildly Unix-compatable there would be no Linux today and probably Micorsoft would be considered a rather benign directing force in the computer industry.
As many have pointed out, installing Linux is easier than installing Windows, an obvious result when you consider that installation is vital to get people to run Linux, while unneccessary for Windows.
To the average person, they buy a computer, plug it in, and Windows is running. That is "installation" for Windows. There is no way Linux is going to do that unless machines have it already installed when you buy it from the store.
If the user is expected to be able to download executable programs (a useful ability, unfortunately) the download program must have the ability to turn on the executable bit, so the fact that it is a bit is probably no more protection than a requirement that the file end in ".exe".
I think the executable bit is a simple "attribute" that everybody seems so gung-ho on adding to file systems. In my opinion that is going to be as safe as the file-naming scheme used on Windows and it is annoying that there is so many claims that filesystem A will clobber B because it has attributes.
A safe system would use a program like "file" to identify exactly what is in the file and act on that. In fact, why isn't Linux persuing this?
"attributes" should be considered a cache of information that programs like "file" figure out. For instance the file type, program to run, postagestamp image, etc. It should be harmless to strip all the attributes, they will be recreated (the only harm is that things slow down). And file transmission protocols should be unable to send attributes, to enforce their use as a cache-only mechanism.
Obviously they are stuck with them now, but it does seem strange they did not change them for the very first version of OS/X, however. I don't think Apple is really trying to hide the NeXT basis, otherwise they would have done obvious changes like this. They probably could have figured out pretty reliable scripts to translate all their existing programs quickly.
Part of their problem was a refusal to provide a hard disk by default.
My company purchased a NeXT cube and I did a considerable amount of programming on it. This machine had a hard disk added, otherwise it was unusable. I certainly encountered many private and small business owners of NeXT machines in selling our software (a terminal emulator with the weird name of Communicae).
I believe even the original system, though supposedly based on Mach, had a "BSD personality" that really provided most of the operating system kernel. They tried to hide the fact that it was BSD doing most of the work, but I never saw any hint that file i/o or any other Unix call had a Mach message behind it. Mach messages were used strictly for GUI applications to talk to each other, not to the outside world or any hardware. So it is quite possible NeXT was closer to modern OS/X than many here believe.
Back compatability can be done with a new xlib that translates the old calls to the new system.
Some calls are a pain, for instance support for colormaps is almost impossible or very inefficient on top of any reasonable modern graphics system that does not have them. Fortunately programs that require colormaps have pretty much disappered (mostly due to XFree86 not supporting colormaps). This does require the new system to support things at a sufficienly low level that Xlib can be done efficiently, this is frustrating for the crowd that believes widgets should be on the server (I disagree so I like this limitation).
Would using Xt, instead of drawing, speed GTK/QT up?
Not at all. Modern toolkits do not use Xt for very good reasons.
Qt and KDE and every other portable tookit (except wxWindows, apparently) do not use the Windows widgets for very good reasons: they cannot add any new features to them. For instance GTK's assignment of shortcuts while you are using the menu. It is also impossible to portably subclass them in user programs and change how they draw or react to events, both of which are major features missing from wxWindows.
99.5% of the "consistent user interface" can be achieved if the system provides a "draw the rectangle for a button here" call, rather than a "button object". This is also much easier to implement and a much easier and bug-free and fast interface than Win32 style objects. Nothing is wrong with having an object interface, but it should be at a library level above a clean and debugged lower level designed so that multiple object sets can coexist.
Fortunatley there is some signs that Windows is starting to provide this, and maybe the KDE + Qt guys can get organized enough to modify their shared themes into this as well...
Because they are calling things like SystemParametersInfo() and GetSysColor() so they can draw their widgets the same. They may also be calling the "draw a button box" call (I don't know what it is called).
I believe my main contributions was that resize was controlled by identifying the rows & columns to resize, rather than individual child widgets. Also the ability to make a widget occupy more than one cell (though there was precedence for occupying an entire row or column).
No, Qt does not use the Windows Win32 widgets. It uses GDI32 to draw things, which is equivalent to using Xlib on Linux.
Next time before you post, check your facts, so you won't look like an idiot.
There are other widget kits that run on Windows: fltk, fox, Xt. And every 3D modelling system (Houdini, Blender, Maya, etc) uses their own toolkit. Also games seem to be quite popular and they don't use the Win32 widgets either.
Wrong. The GPL uses copyright to force anybody redistributing a modified version of the code to release the code. Without copyright there is nothing forcing anybody using the code to do anything, and they can keep their modified version secret, thus contributing *less* to the public domain.
I believe this "policy" is only for low-level employees not trusted to keep secret the fact that Microsoft does not believe their own FUD. You can be sure that some people there are reading GPL code all they want.
Your friend was not high enough in the hierarchy to avoid getting the normal FUD about the GPL from them. Microsoft employs tens of thousands of people, it would be silly of them to suddenly tell the truth when a person is employed, as though that person would not leak this information out.
Microsoft's top developers are well aware that they can look at GPL code all they want, as long as they don't copy it. They probably do. They also look at any other code they can get their hands on, such as from 3rd-party vendors, hardware manufacturers device drivers, etc, all of which they cannot copy either.
"requiring a kernel patch" has nothing to do with "undocumented API". It is a *missing* API. If you run Windows 3.1 there are missing API's as well, and you could say that upgrading to WindowsXP is a patch.
Whether or not these patches are good (no, they probably are not) they have NOTHING to do with "undocumented APIs".
The GPL is strictly based on copyright. You can copy ideas from it, just as long as you don't copy code. You are confusing this with the type of NDA you have to sign to see code from Microsoft. Also Microsoft is very interested in spreading the myth that even looking at GPL code can "contaminate" you, in order to make it sound as bad as their NDA, and you are buying right into this. It isn't, and they know this. So I would not be suprised if they let their top people (the ones trusted to not blab that Microsoft is not practicing their own propaganda internally) to look at Linux source code all they want.
Serious designers want to do things differently, and it turns out that copying source code is pretty useless for this anyway.
Oh yes, I am aware of the Nichimen products. I agree they have the style of interface I am talking about. Personally I have not used it, only seen it being used, but it just looks right to me, and the users have told me that it works and they love the larger visible area.
Too bad they seem to be a niche market. Even Blender is better-known than their stuff.
He was also an excellent speaker, very entertaining. He had used his program to draw characters from the movies shown in the Electronic Theatre during the show.
The program I thought was brilliant. It is what user interface should be, not a thousand menus and "toolbars" but an empty window that you click on and it "does what you want". Too bad there is no sign of such interfaces showing up in real-world applications, either open or closed...
Whether you hate DRM or not, this is how it must be done if it is really going to work. Hardware manufacturers have to get together and design sealed and tamper-proof hardware that does this, and stop listening to Mr Gates saying it will all be done by Palladium. They are being taken for a ride so that Gates can screw the entire rest of the computer industry and put them out of business, and possibly also extract a nasty licensing fee from every content producer.
If you are a content provider and you want DRM that works, you should insist on a sealed hardware device where the manufacturer has published all the specs and enough information that a Linux driver can be written. Not because of the trivial amount of extra business by Linux, but because this is a guarantee that the DRM cannot be broken. The hardware device will have an ID in it (which is going to drive privacy advocates nuts, but what kind of horrors do you think Microsoft's DRM will have?) so that you can download content that will only play on your device.
If anybody is still too dense to get it: the API is similar to the remote control on your DVD player. Yep, you can push those buttons in any order you want, but you are not going to get it to do anything other than play that DVD on your TV.
Microsoft is going to fight this with everything they got, because they will lose the ability to lock-in media playback to their software. They will LIE about how their software will prevent cracks. Listen to your own engineers, and do not believe crap from Microsoft!
I absolutely agree. The end result of DRM is recording devices will be illegal. In the future, after all these DRM schemes have been cracked, content industries can (truthfully) point out that 99.5% of the use of digital recording devices is to violate copyright and that it is perfectly logical.
They will conviently ignore the fact that the remaining 00.5% is all the free speech in the world.
This IS going to happen unless these schemes are stopped now
I will tell you right now, and I SWEAR this is true, that I would have bought many songs from the Apple Music Store if they were MP3 and thus I could transfer them to my desktop machine and play them (I would also put them on an Ipod I own and on the Ibook I used to download them). So for me at least, the DRM has stopped me from making purchases from their site.
Instead I am using the Ibook to rip CD's. For some reason it turns *those* into MP3 files and I can play them anywhere. But isn't this just as much as a possible piracy problem as downloading them?
Actually ripping the CD's has made me remember some old stuff, and I actually went out to buy another album from one of the groups (Carter USM) so in this case the fact that it made MP3's actually *increased* sales.
There is lots of shrill anti-RIAA hysteria here, but even a calm analysis shows that they are wrong, and DRM is only hurting them.
PS: I do believe the RIAA has every right to use any legal means they want to go after people purposely violating their copyright by making copies available on the internet. This is complelety different than annoying paying customers with DRM, and it is totally logical to be in favor of one and against another, though the trolls here will try to say that people must be entirely on one side or the other.
Slashdot Mirror
That is absolutely correct. Any "unification" of Windows is due to the fact that programmers of other toolkits copied the GDI32 and MFC ones. In fact most of the unification on Linux is due to people copying Windows, not from any plan or from copying each other.
Windows programs probably use many times more toolkits than Unix. Except for GTK, ALL the Unix toolkits have a Windows version, plus there are dozens of Windows-only toolkits. Therefore there are more Windows toolkits than Unix. I can confirm that quite a few different ones are being used for Windows programs. Also high-end 3D software and other production software like Avid like to use their own in-house toolkits, so that they can access widgets that don't exist anywhere else.
Yet idiots keep posting here their belief that Windows has a single toolkit and that is why it is "unified". That is FALSE. The reason there is unification is because of toolkits copying each other, something that is finally happening in Linux as well.
That's what wxWindows does.
True, but IBM was planning the same deal with Digital Research for CPM/86, so they would have ended up in Microsoft's position.
I think whoever ended up in that position (IBM itself if it had done the deals right) would have turned into an evil monopoly. Several would have been far worse than Microsoft is, probably. And Bill Gates would be posting on Slashdot and complaining about the monopoly.
drive letters are primarily provided for backwards compat. They're slowly going away.
:/
Okay, tell me how to open a file on the A: drive without starting it with "A:". And make sure it is a name I can figure out from the normal file browser.
$HOMEDRIVE and $HOMEPATH are both defined on this XP machine.
Okay, tell me how that is compatable with the single environment variable $HOME
you can make files (and other objects) case sensitive if you like; services for UNIX install will do this for you if you so desire.
Not if you want any other programs to be able to read/write them.
Services for UNIX does include many GNU utilities..
Services for Unix is not included by default.
UTF-8 is a poor standard - it's what happens when there's too much legacy tied to ANSI C and C style strings. With UTF-8, strlen no longer means anything
strlen() means HOW MANY BYTES ARE IN THE STRING. A VERY useful value. You obvioulsly have ZERO experience with writing any software if you think the number of letters the user sees is a useful value.
UCS-2 from the ground up - a much more reasonable way to do unicode
Read up on "combining characters" before you put your foot in your mouth again. UCS-2 has NO advantages over UTF-8, it's only plausable advantage (fixed-size characters) was obsolete long ago.
I'm not sure why I am dignifying your stuff with a response, but the ignorance here is unbelievable...
Drive letters, ^M^J translation built into the OS, lack of environment variables like $HOME, non-GMT time stamps on the files, inability to handle many punctuation marks in filenames and ISO-8859-1 case-insensitivity and thus the inability to handle UTF-8 correctly in filenames, refusal to provide some GNU tools like a Unix shell...
All of these little details cause us far more grief than the differences in the GUI. And Microsoft could address these easily, eliminating a huge fraction of the hostility that is directed at them. This is what most people are talking about when they say "standards compliant" or whatever.
There is no need for them to provide Linux ABI compatability or even POSIX compatability. What they need to do is to stop ignoring the simple little details where it is obvious to everybody that the Unix design is better. I really think this direct ignorance and disrespect for everybody is the real reason so many hate Microsoft, not because of their closed and monopolistic nature. If NT had been even mildly Unix-compatable there would be no Linux today and probably Micorsoft would be considered a rather benign directing force in the computer industry.
As many have pointed out, installing Linux is easier than installing Windows, an obvious result when you consider that installation is vital to get people to run Linux, while unneccessary for Windows.
To the average person, they buy a computer, plug it in, and Windows is running. That is "installation" for Windows. There is no way Linux is going to do that unless machines have it already installed when you buy it from the store.
If the user is expected to be able to download executable programs (a useful ability, unfortunately) the download program must have the ability to turn on the executable bit, so the fact that it is a bit is probably no more protection than a requirement that the file end in ".exe".
I think the executable bit is a simple "attribute" that everybody seems so gung-ho on adding to file systems. In my opinion that is going to be as safe as the file-naming scheme used on Windows and it is annoying that there is so many claims that filesystem A will clobber B because it has attributes.
A safe system would use a program like "file" to identify exactly what is in the file and act on that. In fact, why isn't Linux persuing this?
"attributes" should be considered a cache of information that programs like "file" figure out. For instance the file type, program to run, postagestamp image, etc. It should be harmless to strip all the attributes, they will be recreated (the only harm is that things slow down). And file transmission protocols should be unable to send attributes, to enforce their use as a cache-only mechanism.
Obviously they are stuck with them now, but it does seem strange they did not change them for the very first version of OS/X, however. I don't think Apple is really trying to hide the NeXT basis, otherwise they would have done obvious changes like this. They probably could have figured out pretty reliable scripts to translate all their existing programs quickly.
Part of their problem was a refusal to provide a hard disk by default.
My company purchased a NeXT cube and I did a considerable amount of programming on it. This machine had a hard disk added, otherwise it was unusable. I certainly encountered many private and small business owners of NeXT machines in selling our software (a terminal emulator with the weird name of Communicae).
I believe even the original system, though supposedly based on Mach, had a "BSD personality" that really provided most of the operating system kernel. They tried to hide the fact that it was BSD doing most of the work, but I never saw any hint that file i/o or any other Unix call had a Mach message behind it. Mach messages were used strictly for GUI applications to talk to each other, not to the outside world or any hardware. So it is quite possible NeXT was closer to modern OS/X than many here believe.
Back compatability can be done with a new xlib that translates the old calls to the new system.
Some calls are a pain, for instance support for colormaps is almost impossible or very inefficient on top of any reasonable modern graphics system that does not have them. Fortunately programs that require colormaps have pretty much disappered (mostly due to XFree86 not supporting colormaps). This does require the new system to support things at a sufficienly low level that Xlib can be done efficiently, this is frustrating for the crowd that believes widgets should be on the server (I disagree so I like this limitation).
Would using Xt, instead of drawing, speed GTK/QT up?
Not at all. Modern toolkits do not use Xt for very good reasons.
Qt and KDE and every other portable tookit (except wxWindows, apparently) do not use the Windows widgets for very good reasons: they cannot add any new features to them. For instance GTK's assignment of shortcuts while you are using the menu. It is also impossible to portably subclass them in user programs and change how they draw or react to events, both of which are major features missing from wxWindows.
99.5% of the "consistent user interface" can be achieved if the system provides a "draw the rectangle for a button here" call, rather than a "button object". This is also much easier to implement and a much easier and bug-free and fast interface than Win32 style objects. Nothing is wrong with having an object interface, but it should be at a library level above a clean and debugged lower level designed so that multiple object sets can coexist.
Fortunatley there is some signs that Windows is starting to provide this, and maybe the KDE + Qt guys can get organized enough to modify their shared themes into this as well...
Because they are calling things like SystemParametersInfo() and GetSysColor() so they can draw their widgets the same. They may also be calling the "draw a button box" call (I don't know what it is called).
I believe my main contributions was that resize was controlled by identifying the rows & columns to resize, rather than individual child widgets. Also the ability to make a widget occupy more than one cell (though there was precedence for occupying an entire row or column).
No, Qt does not use the Windows Win32 widgets. It uses GDI32 to draw things, which is equivalent to using Xlib on Linux.
Next time before you post, check your facts, so you won't look like an idiot.
There are other widget kits that run on Windows: fltk, fox, Xt. And every 3D modelling system (Houdini, Blender, Maya, etc) uses their own toolkit. Also games seem to be quite popular and they don't use the Win32 widgets either.
Wrong. The GPL uses copyright to force anybody redistributing a modified version of the code to release the code. Without copyright there is nothing forcing anybody using the code to do anything, and they can keep their modified version secret, thus contributing *less* to the public domain.
I believe this "policy" is only for low-level employees not trusted to keep secret the fact that Microsoft does not believe their own FUD. You can be sure that some people there are reading GPL code all they want.
Your friend was not high enough in the hierarchy to avoid getting the normal FUD about the GPL from them. Microsoft employs tens of thousands of people, it would be silly of them to suddenly tell the truth when a person is employed, as though that person would not leak this information out.
Microsoft's top developers are well aware that they can look at GPL code all they want, as long as they don't copy it. They probably do. They also look at any other code they can get their hands on, such as from 3rd-party vendors, hardware manufacturers device drivers, etc, all of which they cannot copy either.
"requiring a kernel patch" has nothing to do with "undocumented API". It is a *missing* API. If you run Windows 3.1 there are missing API's as well, and you could say that upgrading to WindowsXP is a patch.
Whether or not these patches are good (no, they probably are not) they have NOTHING to do with "undocumented APIs".
The GPL is strictly based on copyright. You can copy ideas from it, just as long as you don't copy code. You are confusing this with the type of NDA you have to sign to see code from Microsoft. Also Microsoft is very interested in spreading the myth that even looking at GPL code can "contaminate" you, in order to make it sound as bad as their NDA, and you are buying right into this. It isn't, and they know this. So I would not be suprised if they let their top people (the ones trusted to not blab that Microsoft is not practicing their own propaganda internally) to look at Linux source code all they want.
Serious designers want to do things differently, and it turns out that copying source code is pretty useless for this anyway.
Oh yes, I am aware of the Nichimen products. I agree they have the style of interface I am talking about. Personally I have not used it, only seen it being used, but it just looks right to me, and the users have told me that it works and they love the larger visible area.
Too bad they seem to be a niche market. Even Blender is better-known than their stuff.
No ZBrush is totally different. It is interested in filling in areas, this is interested in the boundaries of areas.
He was also an excellent speaker, very entertaining. He had used his program to draw characters from the movies shown in the Electronic Theatre during the show.
The program I thought was brilliant. It is what user interface should be, not a thousand menus and "toolbars" but an empty window that you click on and it "does what you want". Too bad there is no sign of such interfaces showing up in real-world applications, either open or closed...
Whether you hate DRM or not, this is how it must be done if it is really going to work. Hardware manufacturers have to get together and design sealed and tamper-proof hardware that does this, and stop listening to Mr Gates saying it will all be done by Palladium. They are being taken for a ride so that Gates can screw the entire rest of the computer industry and put them out of business, and possibly also extract a nasty licensing fee from every content producer.
If you are a content provider and you want DRM that works, you should insist on a sealed hardware device where the manufacturer has published all the specs and enough information that a Linux driver can be written. Not because of the trivial amount of extra business by Linux, but because this is a guarantee that the DRM cannot be broken. The hardware device will have an ID in it (which is going to drive privacy advocates nuts, but what kind of horrors do you think Microsoft's DRM will have?) so that you can download content that will only play on your device.
If anybody is still too dense to get it: the API is similar to the remote control on your DVD player. Yep, you can push those buttons in any order you want, but you are not going to get it to do anything other than play that DVD on your TV.
Microsoft is going to fight this with everything they got, because they will lose the ability to lock-in media playback to their software. They will LIE about how their software will prevent cracks. Listen to your own engineers, and do not believe crap from Microsoft!
I absolutely agree. The end result of DRM is recording devices will be illegal. In the future, after all these DRM schemes have been cracked, content industries can (truthfully) point out that 99.5% of the use of digital recording devices is to violate copyright and that it is perfectly logical.
They will conviently ignore the fact that the remaining 00.5% is all the free speech in the world.
This IS going to happen unless these schemes are stopped now
I will tell you right now, and I SWEAR this is true, that I would have bought many songs from the Apple Music Store if they were MP3 and thus I could transfer them to my desktop machine and play them (I would also put them on an Ipod I own and on the Ibook I used to download them). So for me at least, the DRM has stopped me from making purchases from their site.
Instead I am using the Ibook to rip CD's. For some reason it turns *those* into MP3 files and I can play them anywhere. But isn't this just as much as a possible piracy problem as downloading them?
Actually ripping the CD's has made me remember some old stuff, and I actually went out to buy another album from one of the groups (Carter USM) so in this case the fact that it made MP3's actually *increased* sales.
There is lots of shrill anti-RIAA hysteria here, but even a calm analysis shows that they are wrong, and DRM is only hurting them.
PS: I do believe the RIAA has every right to use any legal means they want to go after people purposely violating their copyright by making copies available on the internet. This is complelety different than annoying paying customers with DRM, and it is totally logical to be in favor of one and against another, though the trolls here will try to say that people must be entirely on one side or the other.