It was a major innovation when AT&T released a C++ compiler that worked by compiling the C++ code into C code instead of assembler. It allowed the new language to be supported in a fraction of the time required before.
Er, no. The very first C++ compiler did this. So did a lot of the early ones. At least one still does (Cousteau C++).
Well, he re-defines what he's asking for at least 3 times. He wants stuff that Solaris can do that Linux can't. No, wait, he wants to know how Linux is different than SVR4. No, he wants to know which one is better for teaching.
He's got a point that Linux isn't causing any revolutions in OS technology. But he dithers and blathers around so much it's hard to even see that statement for what it is - it almost sounds like he's saying you may as well use SVR4 instead because it's the same basic concepts(!).
Honestly, this is the sort of thing I'd expect to see left on a publishers desk at 4AM, with the faint smell of coffee and bourbon lingering in the air. It's incoherent, rambling, and of marginal if any technical value (programmers don't want threads because they only mimic concurrency?!). He doesn't have the technical skills to evaluate the differences he's supposedly looking for, but he decides to draw conclusions anyway. He needs to really decide what he wants, why he wants it, and then to move from there. And while he does that, it'd be nice if he didn't spew any more half-realized thoughts into his articles on LinuxInsider.
There's been a lot of MMORPGs. Every single one of the major ones has been plauged with problems like this. Maybe it's just not an easy problem? If it were just Sony or something I could understand saying that they don't know what they're doing. I seriously doubt that every single successful MMO is run soley by clueless people who don't know how to do stress analysis.
I hope they've started following it recently, because there were many sections I found where the HIG said one thing and their Office suite did something completely different.
A huge problem for anyone who's trying to conform to the guidelines. "That's the standard!" "Well, it's not what Office does!".
I have the same complaint about Apple, by the way, although they cover themselves by editing the HIG every time they do something stupid, like brushed metal.
Could you point me to some place in MSDN which describes how to output text with kerning in GDI/GDI+? Because if you can't (and I bet you can't, because it's not there) then you're the one with the head you know where.
The ExtTextOut function is the one you want. I believe, although I'm not 100% certain and can't check right now, that the basic GDI+ text drawing functions support kerning. That's real kerning, based on OpenType fonts. Fonts without kerning information will obviously not be kerned.
DirectX does compositing, but in its current design it only works well with one drawing thread.:0)
Does OSX really allow you to draw from more than one thread? Most OSes don't do this because it's a performance hit. You can if you really want to in Windows, but most people don't.
And I don't see any flicker in Mac OS X. None. Zero. Double buffering or triple buffering - I don't give a shit. If I need to spend $50 on additional RAM, it's fine with me. It's hard to use Windows and (especially) Linux after Mac OS X.
See, now you're redefining your claims. You can do flicker-free drawing on Windows if you want to. It's a design choice based on trade-offs with RAM usage and performance vrs. memory usage. A lot of the native windows controls aren't double buffered because the memory usage would be extreme. Windows does have a couple glitches that make flickering common, like the seperate WM_ERASE and WM_PAINT messages, which I won't defend, but you can work around those. OS X chose to sacrifice performance and RAM in the interests of global double buffering. Windows didn't, which makes far more sense for it's market. It's not a case of "Haha M$ sucks they can't even double buffer", it's an informed judgment call. I've seen OS X apps that flicker, by the way. It's not hard - you just need to do naive Windows-style drawing, where you erase and then paint.
They have? Like who? All I've seen have been really, really terrible attempts and publishing regular applications. Except slower, and less user friendly.
XP displays a set of radio buttons to select what privileges to assign new users. "Administrator" is the default, but it's not hard to click on one of the other buttons.
I don't remember seeing this, but then it's been a while since I installed XP. You can set it when you create new users after installation, but the interface is designed to be "simple" and doesn't give you much information. Most users will run as Admin because thats the default and because they're discover stuff not working if they don't. Simple as that.
Many Linux setup/install programs don't require you to create any users other than root, and some will even allow you to assign a null password to the root acount.
Ehhhh... many? Debian, Mandrake, SuSe, and Redhat don't. That accounts for probably 90% of non-expert linux installs.
You're comparing the worst case for extensions (random extension from a random webpage) with the average case for ActiveX (same thing) and deciding that they're equal. They aren't. First off, Firefox won't install an extension silently from anyone, trusted or not. There's a whitelist for sources and if you aren't on the whitelist you don't even get to ask the user, it's that simple. ActiveX will silently install in any number of circumstances, inlcuding updates to existing controls, controls from a publisher declared to be trusted, or controls using one of the well-known zone bypasses. There's very little information given in the IE confirmation dialog and none of it is usefull for determining the provenance of code. On the other had, extensions on updates.mozilla.org are vetted by the community, and while there's a window of risk if malware get's published, there's a single source to contain. I have only to point to the braod amount of signed, perfectly legitimate appearing spyware ActiveX controls. Further, there's no way to manage trust in IE - once you're trusted a control, you can't (non-trivially) revoke it. If you've trusted a publisher, even worse. The entire chain of control, from top to bottom, is poorly implemented and designed. The extension model isn't perfect, but it's superior to the ActiveX/IE model. It's all based on trust, but the design decisions of IE minimize your ability to confirm that trust, and then maximize your ability to accidently grant trust.
This is even more true if you're an ActiveX control with access to an interactive desktop. There's a ton of things you can do with the graphics system to escalate privledges and MS isn't really interested in fixing them - access to an interactive desktop is considered a barrier and once you're past it much less stringent rules apply.
It's real simple: because there's a centralized source for extensions. There's not "controls.microsoft.com" where you can go to install activeX controls. They're provided independently by web pages. Signed controls can be provided by almost anyone (as someone else noted, a lot of spyware is signed) because there's no assertation of correctness with signing. It does generally prevent random malware (because it costs money), but it doesn't prevent the much larger class of commercial malware.
Futhermore, the security interface for ActiveX sucks balls - if you accept a control once, your browser will happily upgrade it when you go to that page next, whether or not you want to. It's really, really easy to accidently install an ActiveX control, signed or not. Extensions are in a very different ballpark than ActiveX controls, althought they do have some of the same issues. Why are you so dead-set on defending this totally braindead and almost universally despised technology? Not even Microsoft claims they're a good idea.
DirectX can do realtime compositing. Basic ("normal") GDI doesn't.
There's nothing flicker-free about OS X graphics, either. The OS double buffers (one reason OS X is such a pig for RAM) for you so you can skip some of the optimizations, but double buffering isn't magic and won't stop all flicker. You use exactly the same techniques for no-flicker drawing on Windows as you would on OS X. Double buffering works fine on Windows, and the blit is hardware accelerated, people don't use it because of the memory cost (it's not worth doubling your RAM usage to prevent corner-case flicker).
As for tyography, you've got your head up your ass. GDI does and has supported all sorts of advanced text rendering, including kerning. GDI+ does it a lot better.
Pretty much the only thing in your post which is correct is that Windows doesn't use vector graphics. Yay. That's not the same as not being available, but they aren't built into the system.
Why are you using XML? If you're using it for buzzword compliance, then you're wrong. And nobody but your PHBs cares anyway so it doesn't matter. If you're using it for interchange with other companies, then why are you worried about inefficency, and why is compressing it too much of a barrier? There's lots of obstacles in the way of direct communication with other businesses, compressing your XML is pretty trivial. If you're using it internally as an exchange format, maybe you should consider using something else. There's quite a few alternatives to XML, depending on exactly what you're doing.
Disclaimer: I detest XML with a passion. However, it has some good points:
1: Widespread adoption. Anyone who can't parse XML is someone you don't want to be doing business with anyway.
2: Flexible. Highly compressable plain text means it can go over almost any transport with minimal if any extra work.
3: The ability to validate against a DTD is invaluable for interchange. It's not the magic interopability the trade rags would have you believe, but if you've ever written parsing and validating code for a binary interchange standard then you'll really value a standard format with a standard validation scheme
Now, XML certainly has it's bad points. And it's made even worse by the hype. But it really does have advantages.
I think this is really one of the problems with business process patents - one-click shopping is innovative. But it's not technically innovative - it's trchnically pretty trivial. The innovative part is recognizing that customers want this and delivering it to them. This is traditionally the sort of thing that good companies do and gain market advantage from. But by extending patents to this, we basically extend first-mover advantage from some arbitrary market-defined amount of time (quite short for fast-moving markets like the Internet) to a flat 14 years. Worse, we then close off benefits to consumers (consumers would be benefited if other stores had one-click, too) just to protect this idea.
It's true, but lets face facts - most business people are FAR more comfortable with ye olde "give me money" licensing model (I'm not familiar with CE licensing specifically most Windows licensing is of this type) than they are with anything else. There are people who would rather pay money and be on stable mental ground than even use a BSD license, much less the GPL.
Process patents are a recent concept. I don't remember the exact date, and I'm too lazy to search, but I believe they were introduced in the 70s, more or less at the behest of genetic research companies (software companies didn't have enough leverage then). I should clarify what I mean by a process patent - you could always patent the MECHANICS of a process, like a smelter for creating steel. You couldn't patent the process of creating steel. With software/business process patents, you can do the equivilent. The Eolas patent on embedded objects was a great example - the actual mechanics of doing the embedding are the hard part, and were not adressed at all by the patent. Note that this patent was upheld in multiple court decisions.
I didn't say you couldn't get sucessful by selling your engine design to existing companies. I said you'd have a hard time marketing a new car. I know the difference, do you?
And Edison is actually a really good example. Maybe you don't remember when we broke up the energy monopolies and forced a market? It's hard to play what-if in economics, but I'd say that we weren't served in the long run by Edison's capitalist greed - we had to take measures after the fact to correct the situation.
There's a level in Thief 3 that's the scariest thing I've ever played, SS2 included. You are in 100% zero danger for the first half of the level - there are no enemies and nothing that can hurt you. Even replaying it, when I KNEW that, I still was scared out of my mind. THAT is atmosphere.
Well, I kinda look at it like this. We can't judge the merits of a system we don't have. So lets look at the history of our existing system and see how much innovation has been spurred by software patents, and how much has been supressed. The first is really easy to measure by how many novel patents are granted, how many products based on those patents are created, and how sucessfull those patents are.
Patents work really good for protecting mature industries where true innovation is both revolutionary and rare. Incidently, these are also the industries where small players are the least likely to be able to make a dent - you're going to have a tough time selling a new car even if you have some nifty new engine that has all the performance of a V8 but 100x the gas mileage. Patents work really poorly in rapidly evolving new industries (and there's never been an industry that's moved as fast as software is).
Further, patents are supposed to be on an INVENTION, not a PROCESS. That's why you can't patent mathematical theorems.
It's a pretty big topic. There's arrangement and organization of buttons. There's stuff like platform specific dialog boxes (file choosers, for example) and associated behavior, such as whether or not a dialog should center on it's parent or on the screen. There's the behavior of common controls (should drop down boxes scroll through options on arrow key, or drop down the list?). Common hotkey accelerators (especially on the Mac).
Making an acceptable cross platform application is non-trivial, and using something like GTK for it just tosses everything out the window. Note that PROGRAM behavior can remain the same, it's the interaction with the user which is expected to be consist. Some people don't care, of course, and that's fine, but most people care to some degree and some people (like me) care a whole lot. My major hatred is reserved for people who claim that GTK is a cross-platform toolkit because it has a Windows port. This makes Baby Jesus cry. GTK is a great toolkit if you're targeting GNOME, an adequate one if you're just targeting X-Windows (or a framebuffer, or any other environment that doesn't have a default behavior and/or widget set), and a piss poor one if you want an application that's acceptable to regular users of Windows or Mac OS. Sometimes you can pass it off to a Windows users as a "skin" and convince them it's better, but Mac users just won't find it acceptable.
The Windows versions suck is the gist of my rant. They suck exactly because they operate the same as thier Linux counterparts, rather than as Windows applications. A good cross platform application should act appropriately for the current platform, not stick out like a sore thumb. Note that this means a lot more than just theming (although GTK-Win32s support for Windows theming leaves a lot to be desired anyway).
A port is probably pretty simple as long as you're willing to accept the terrible rape of all that is Good and Just that masquerades as GTK-Win32. A port that people will actually want to use without endangering their unborn children will need to be re-written (in a cross-platform toolkit, or directly against Windows) and would almost certainly be non-trivial.
OSS wouldn't have fixed this, as I understand it. The 16 bit limit was a known and documented limitation of the system. There was even an upgrade path in place. It wasn't premature optimization - when written, saving those bits made a huge difference. They got bit by a combination of organizational inertia and bad luck more than anything.
Slashdot Mirror
Er, no. The very first C++ compiler did this. So did a lot of the early ones. At least one still does (Cousteau C++).
He's got a point that Linux isn't causing any revolutions in OS technology. But he dithers and blathers around so much it's hard to even see that statement for what it is - it almost sounds like he's saying you may as well use SVR4 instead because it's the same basic concepts(!).
Honestly, this is the sort of thing I'd expect to see left on a publishers desk at 4AM, with the faint smell of coffee and bourbon lingering in the air. It's incoherent, rambling, and of marginal if any technical value (programmers don't want threads because they only mimic concurrency?!). He doesn't have the technical skills to evaluate the differences he's supposedly looking for, but he decides to draw conclusions anyway. He needs to really decide what he wants, why he wants it, and then to move from there. And while he does that, it'd be nice if he didn't spew any more half-realized thoughts into his articles on LinuxInsider.
There's been a lot of MMORPGs. Every single one of the major ones has been plauged with problems like this. Maybe it's just not an easy problem? If it were just Sony or something I could understand saying that they don't know what they're doing. I seriously doubt that every single successful MMO is run soley by clueless people who don't know how to do stress analysis.
I promise that if you really do succeed and create a new computing paradigm, I'll be gracious when you point your finger and laugh.
A huge problem for anyone who's trying to conform to the guidelines. "That's the standard!" "Well, it's not what Office does!".
I have the same complaint about Apple, by the way, although they cover themselves by editing the HIG every time they do something stupid, like brushed metal.
You go ahead and do that, and then when nobody we wants it we can all point and laugh, okay?
The ExtTextOut function is the one you want. I believe, although I'm not 100% certain and can't check right now, that the basic GDI+ text drawing functions support kerning. That's real kerning, based on OpenType fonts. Fonts without kerning information will obviously not be kerned.
DirectX does compositing, but in its current design it only works well with one drawing thread. :0)
Does OSX really allow you to draw from more than one thread? Most OSes don't do this because it's a performance hit. You can if you really want to in Windows, but most people don't.
And I don't see any flicker in Mac OS X. None. Zero. Double buffering or triple buffering - I don't give a shit. If I need to spend $50 on additional RAM, it's fine with me. It's hard to use Windows and (especially) Linux after Mac OS X.
See, now you're redefining your claims. You can do flicker-free drawing on Windows if you want to. It's a design choice based on trade-offs with RAM usage and performance vrs. memory usage. A lot of the native windows controls aren't double buffered because the memory usage would be extreme. Windows does have a couple glitches that make flickering common, like the seperate WM_ERASE and WM_PAINT messages, which I won't defend, but you can work around those. OS X chose to sacrifice performance and RAM in the interests of global double buffering. Windows didn't, which makes far more sense for it's market. It's not a case of "Haha M$ sucks they can't even double buffer", it's an informed judgment call. I've seen OS X apps that flicker, by the way. It's not hard - you just need to do naive Windows-style drawing, where you erase and then paint.
They have? Like who? All I've seen have been really, really terrible attempts and publishing regular applications. Except slower, and less user friendly.
I don't remember seeing this, but then it's been a while since I installed XP. You can set it when you create new users after installation, but the interface is designed to be "simple" and doesn't give you much information. Most users will run as Admin because thats the default and because they're discover stuff not working if they don't. Simple as that. Many Linux setup/install programs don't require you to create any users other than root, and some will even allow you to assign a null password to the root acount.
Ehhhh... many? Debian, Mandrake, SuSe, and Redhat don't. That accounts for probably 90% of non-expert linux installs.
You're comparing the worst case for extensions (random extension from a random webpage) with the average case for ActiveX (same thing) and deciding that they're equal. They aren't. First off, Firefox won't install an extension silently from anyone, trusted or not. There's a whitelist for sources and if you aren't on the whitelist you don't even get to ask the user, it's that simple. ActiveX will silently install in any number of circumstances, inlcuding updates to existing controls, controls from a publisher declared to be trusted, or controls using one of the well-known zone bypasses. There's very little information given in the IE confirmation dialog and none of it is usefull for determining the provenance of code. On the other had, extensions on updates.mozilla.org are vetted by the community, and while there's a window of risk if malware get's published, there's a single source to contain. I have only to point to the braod amount of signed, perfectly legitimate appearing spyware ActiveX controls. Further, there's no way to manage trust in IE - once you're trusted a control, you can't (non-trivially) revoke it. If you've trusted a publisher, even worse. The entire chain of control, from top to bottom, is poorly implemented and designed. The extension model isn't perfect, but it's superior to the ActiveX/IE model. It's all based on trust, but the design decisions of IE minimize your ability to confirm that trust, and then maximize your ability to accidently grant trust.
This is even more true if you're an ActiveX control with access to an interactive desktop. There's a ton of things you can do with the graphics system to escalate privledges and MS isn't really interested in fixing them - access to an interactive desktop is considered a barrier and once you're past it much less stringent rules apply.
Futhermore, the security interface for ActiveX sucks balls - if you accept a control once, your browser will happily upgrade it when you go to that page next, whether or not you want to. It's really, really easy to accidently install an ActiveX control, signed or not. Extensions are in a very different ballpark than ActiveX controls, althought they do have some of the same issues. Why are you so dead-set on defending this totally braindead and almost universally despised technology? Not even Microsoft claims they're a good idea.
There's nothing flicker-free about OS X graphics, either. The OS double buffers (one reason OS X is such a pig for RAM) for you so you can skip some of the optimizations, but double buffering isn't magic and won't stop all flicker. You use exactly the same techniques for no-flicker drawing on Windows as you would on OS X. Double buffering works fine on Windows, and the blit is hardware accelerated, people don't use it because of the memory cost (it's not worth doubling your RAM usage to prevent corner-case flicker).
As for tyography, you've got your head up your ass. GDI does and has supported all sorts of advanced text rendering, including kerning. GDI+ does it a lot better.
Pretty much the only thing in your post which is correct is that Windows doesn't use vector graphics. Yay. That's not the same as not being available, but they aren't built into the system.
Maybe they're talking about SVG images.
Disclaimer: I detest XML with a passion. However, it has some good points:
1: Widespread adoption. Anyone who can't parse XML is someone you don't want to be doing business with anyway.
2: Flexible. Highly compressable plain text means it can go over almost any transport with minimal if any extra work.
3: The ability to validate against a DTD is invaluable for interchange. It's not the magic interopability the trade rags would have you believe, but if you've ever written parsing and validating code for a binary interchange standard then you'll really value a standard format with a standard validation scheme
Now, XML certainly has it's bad points. And it's made even worse by the hype. But it really does have advantages.
I think this is really one of the problems with business process patents - one-click shopping is innovative. But it's not technically innovative - it's trchnically pretty trivial. The innovative part is recognizing that customers want this and delivering it to them. This is traditionally the sort of thing that good companies do and gain market advantage from. But by extending patents to this, we basically extend first-mover advantage from some arbitrary market-defined amount of time (quite short for fast-moving markets like the Internet) to a flat 14 years. Worse, we then close off benefits to consumers (consumers would be benefited if other stores had one-click, too) just to protect this idea.
It's true, but lets face facts - most business people are FAR more comfortable with ye olde "give me money" licensing model (I'm not familiar with CE licensing specifically most Windows licensing is of this type) than they are with anything else. There are people who would rather pay money and be on stable mental ground than even use a BSD license, much less the GPL.
Process patents are a recent concept. I don't remember the exact date, and I'm too lazy to search, but I believe they were introduced in the 70s, more or less at the behest of genetic research companies (software companies didn't have enough leverage then). I should clarify what I mean by a process patent - you could always patent the MECHANICS of a process, like a smelter for creating steel. You couldn't patent the process of creating steel. With software/business process patents, you can do the equivilent. The Eolas patent on embedded objects was a great example - the actual mechanics of doing the embedding are the hard part, and were not adressed at all by the patent. Note that this patent was upheld in multiple court decisions.
And Edison is actually a really good example. Maybe you don't remember when we broke up the energy monopolies and forced a market? It's hard to play what-if in economics, but I'd say that we weren't served in the long run by Edison's capitalist greed - we had to take measures after the fact to correct the situation.
There's a level in Thief 3 that's the scariest thing I've ever played, SS2 included. You are in 100% zero danger for the first half of the level - there are no enemies and nothing that can hurt you. Even replaying it, when I KNEW that, I still was scared out of my mind. THAT is atmosphere.
Patents work really good for protecting mature industries where true innovation is both revolutionary and rare. Incidently, these are also the industries where small players are the least likely to be able to make a dent - you're going to have a tough time selling a new car even if you have some nifty new engine that has all the performance of a V8 but 100x the gas mileage. Patents work really poorly in rapidly evolving new industries (and there's never been an industry that's moved as fast as software is).
Further, patents are supposed to be on an INVENTION, not a PROCESS. That's why you can't patent mathematical theorems.
Making an acceptable cross platform application is non-trivial, and using something like GTK for it just tosses everything out the window. Note that PROGRAM behavior can remain the same, it's the interaction with the user which is expected to be consist. Some people don't care, of course, and that's fine, but most people care to some degree and some people (like me) care a whole lot. My major hatred is reserved for people who claim that GTK is a cross-platform toolkit because it has a Windows port. This makes Baby Jesus cry. GTK is a great toolkit if you're targeting GNOME, an adequate one if you're just targeting X-Windows (or a framebuffer, or any other environment that doesn't have a default behavior and/or widget set), and a piss poor one if you want an application that's acceptable to regular users of Windows or Mac OS. Sometimes you can pass it off to a Windows users as a "skin" and convince them it's better, but Mac users just won't find it acceptable.
The Windows versions suck is the gist of my rant. They suck exactly because they operate the same as thier Linux counterparts, rather than as Windows applications. A good cross platform application should act appropriately for the current platform, not stick out like a sore thumb. Note that this means a lot more than just theming (although GTK-Win32s support for Windows theming leaves a lot to be desired anyway).
A port is probably pretty simple as long as you're willing to accept the terrible rape of all that is Good and Just that masquerades as GTK-Win32. A port that people will actually want to use without endangering their unborn children will need to be re-written (in a cross-platform toolkit, or directly against Windows) and would almost certainly be non-trivial.
OSS wouldn't have fixed this, as I understand it. The 16 bit limit was a known and documented limitation of the system. There was even an upgrade path in place. It wasn't premature optimization - when written, saving those bits made a huge difference. They got bit by a combination of organizational inertia and bad luck more than anything.