Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release.
The problem is WINE is not "undocumented Win32 API calls". CrossOver Office can run MS Office just fine, and if there's any Windows application that would be using "undocumented Win32 API calls", it'd be Office. The fact is that there aren't any useful undocumented API functions. What's not documented is undocumented for a reason and is not used, even by Microsoft apps.
The problem with WINE is that the Win32 API is so mind-bogglingly huge because it covers just about everything you'd ever want to use an OS to do, that the WINE developers haven't been able to implement the whole thing. They go for the "most bang for the buck" APIs.
Your comment is underrated unless it has (Score: 10, Interesting). Unfortunately, most people here are just going to overlook it and continue spouting their tinfoil hat theories that Word is faster than Open Office because of some secret Microsoft dirty tricks.:(
I just reverted some pages on my watch list on Wikipedia that had been edited with a google spam bot to link all sorts of words back to its mother site....
It's too bad it stays around in Wikipedia's history pages --- meaning the spammer is still getting full value from their links.
Thanks to GameSpy for its 'Pixel' column discussing whether the early days of the PlayStation and Saturn are a newer, but nevertheless interesting stage of 'retro'.
They're not retro yet if people still actually use them. I know people that still play games on their original PlayStation.
Give them another 10 years or so. Nothing picks up speed as being "retro" until the people who grew up with it get to the point where they have the capability of enabling their want for nostalgia.
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
.NET fixes this problem by deprecating use of the registry, preferring systemwide configuration for an application to be in the application's directory, and side-by-side DLL use. They even market the whole idea as enabling "XCOPY Deployment" (referring to the DOS utility XCOPY, which can copy a whole directory tree).
The only shared aspect it has is the GAC, which is really only intended to be used in special cases, not in a general application's use.
So why don't we speak of "Avi movies" instead of DivX movies?
I don't know about you, but I usually refer to them as "AVIs". I couldn't care less as to what sort of encoding is used inside, as long as it plays on my system.
How in the world can you be split over something like that?
The fear of a fork is what keeps the community split. A truly open source Java would have no restrictions against someone taking Java and extending it in a way that's incompatible with existing Java (remember when Microsoft tried to do that?). It would completely undermine the idea of Java as a stable universally-compatible platform to build on.
Re:Is the MONO project a ticking bomb?
on
Mono Beta 2 Released
·
· Score: 2, Insightful
So there is nothing preventing them from doing this. Are we are just hoping that they act like a grown-up, blue chip company?
Their legal commitment to their stockholders to keep their stock values as high as possible is preventing them from doing this. If Microsoft starts making acts of desperation, they'll be seen as a desperate company, and a desperate company's stock prices aren't as high as a well-off company.
While you could make the argument that that's no assurance they won't do it at all; I could point out that there's no assurance they wouldn't incite legal action against just about any open source project for any of the patents in their portfolio, since they have patents that cover just about everything.
And then there's also the fact that they gave up to ECMA what's arguably the part of.NET that would have benefited the most from patent protection, MSIL, which was very cleverly designed to JIT code as optimal as a native compiler would spit out from the same source (as opposed to say, Java's bytecode, which doesn't JIT very well at all due to the complexity of the opcodes, among other factors). The bulk of the Framework classes aren't really much more than a collection of well-known, pre-existing algorithms and concepts (there's not much patentable ground in regards to a String API, or a Stream API, etc.), so even if Microsoft did want to rattle the chains about Mono in that respect, they'd be fighting a weak stance -- they can't just intimidate Miguel de Icaza into giving up on Mono since Novell's got his back and enough money to stand up to Microsoft.
Where Microsoft is going to fight is on the integration with.NET into Windows itself. Longhorn will provide a managed API for everything, and the new features will only be exposed through managed APIs. Avalon and WinFX will make writing.NET apps even easier. They'll always be able to out-.NET Mono, but at the same time they'll reap the benefits of increased interoperability which they'll eventually try to use as leverage to get Windows into more server rooms -- the frontier that Windows is the minority in currently, and the only room for Microsoft to grow into.
That's why Microsoft's not going to take out Mono. That's why they're even plugging Mono on MSDN.
All of the above. The kernel of XP didn't get any additional bloat that would slow it down, and, as I mentioned, it's been improved in many ways over 2K. By turning the visual effects down to 2K levels, you'll get better than 2K performance. Disabling the visual styles, the menu fading animations, and, in my experience, most importantly, the drop shadows on menus and tooltips.
I could see "Unix for people who have no clue about Unix".
Me too, if they were paid by the word. But they're not. They were going for a shorty, catchy, memorable title; and the first book in the series was "DOS for Dummies", so it was a little alliteration as well.
Re:Is the MONO project a ticking bomb?
on
Mono Beta 2 Released
·
· Score: 2, Insightful
What is going to prevent Microsoft from playing the patent card when it suits them?
Microsoft has never used a patent in that manner. Nor do most companies, actually -- patent portfolios are built more for defense than for offense. Making money out of patent litigation is something that fly-by-night vulture companies do, not blue chips like MSFT.
Second, Microsoft has much to lose themselves from shutting down Mono. They often point to Mono as an example of the flexibility and interoperability of their platform, and in fact they even have an interview with Miguel on MSDN to help convince developers of the same thing as well.
Microsoft would seriously have to be pinned against the ropes before they'd make such a desperate move. In fact, I'd be willing to venture that they'd embrace Linux wholeheartedly out of desperation before they'd resort to using patents in that manner.
Re:Any news about the patent review?
on
Mono Beta 2 Released
·
· Score: 2, Interesting
are the relevant ECMA standards 334 and 335 and just RAND, or are they really RAND and royalty free as miguel and others have claimed?
The standards are royalty free, however the standards only cover the CLR (the VM/JIT) and C# the language, not the Framework (all the classes that do stuff).
That's partially why the Mono folks are making two stacks -- the Microsoft-compatible stack, which may be patent encumbered (though Microsoft has never yet used a patent offensively); and the Mono stack, which isn't chained to Microsoft, and better supports Linux anyhow.
Mono is fairly efficient, but there is a lot of room to grow optimization wise.
The Slashdot crowd might be interested to know that recently on the mono-devel list there have been benchmarks and discussions on moving the implemention of Mono's System.String class from native code to managed code since Mono's JIT actually already provides better performance than the native code does in that case.
Though the performance increase (which is 50% in one case!) can be mostly attributed to no longer having to go between managed/native code, that a pure managed solution is faster is impressive on its own regardless.
upgrading from 2K to XP on the same hardware will slow you down.
Unless you turn off the eye candy, in which case XP is measurably faster than 2K, since XP includes reordering and prelinking routines to reduce disk seeking time and relocation time during startup.
the XP booting issue isn't a distro issue but a kernel issue, and the problem was created by MS, not Linus
Bullshit. The problem does not exist if you install FC1 on the same system. Something in Linux changes that breaks system and it's Microsoft's fault? Even if Microsoft is creating an incorrect partition table, previous releases of the Linux kernel supported it just fine, thank you very much. This new behavior is a regression in Linux.
We have here a virus for IA64, a system that's out there in a minimal amount of machines, all high-end (presumably well-protected) servers. Now one of the standard explanations for the lack of viruses for Linux is that Linux is not as widespread. It is, however, much more widespread than IA64. Thus the amount of Linuxen out there is certainly not the only reason we're not seeing virues for Linux. Who knows, maybe Linux *is* actually more secure than Windows?
You act as if there've never been any worms or viruses for Linux...
I don't run linux personally.. but the lack of choice is annoying. I paid for XP pro and I should be able to remove components completely.
Sure you can hack up your copy of XP Pro to try to remove IE entirely. Some people do. But you mentioned yourself, IE is not just a web browser. It provides critical services to almost every application you'd want to run under Windows. Despite all the Slashbot sneering and jeering about the issue, it really is an integral part of Windows, and removing it makes the system about as useful as removing the network stack from Linux.
If your idealism is strong enough that you can't stand IE being used as a library for internet access, or as a layout engine for applications (both uses, I might add, that Mozilla can't just be plugged in as a replacement to fill due to it not being IE-compatible), then your only real solution is to throw the baby out with the bathwater and not use Windows.
Besides the fact that Mozilla was the first on the scene to include an option to block out pop-ups (I haven't bother to check has IE included that option yet?) that alone should be a reason for people to download a separate browser.
That's not a good reason. "Getting there first" doesn't count for beans in software. Case in point, IE was the first on the scene with dynamic reflow and any sort of CSS support, but I doubt you'd point to that as a good enough reason alone for people to use IE today.
If you want popup blocking with IE, you can easily download the Google Toolbar, which is a much smaller and easier download and install than Mozilla -- with less compatibility issues. Or you can wait a month or two until XP SP2 comes out, which builds the functionality right into IE.
Slashdot Mirror
Eventually the WINE development team will crack most of the undocumented Win32 API calls and make WINE better with each release.
The problem is WINE is not "undocumented Win32 API calls". CrossOver Office can run MS Office just fine, and if there's any Windows application that would be using "undocumented Win32 API calls", it'd be Office. The fact is that there aren't any useful undocumented API functions. What's not documented is undocumented for a reason and is not used, even by Microsoft apps.
The problem with WINE is that the Win32 API is so mind-bogglingly huge because it covers just about everything you'd ever want to use an OS to do, that the WINE developers haven't been able to implement the whole thing. They go for the "most bang for the buck" APIs.
But Mac users keep and use their machines for a _lot_ longer- they're actually more like 10% of users.
Bullshit. Google has possibly the most unbiased OS survey (who doesn't use Google?!), and even they say that only 3% of the market is Mac.
Here's an experiment for you.
:(
Your comment is underrated unless it has (Score: 10, Interesting). Unfortunately, most people here are just going to overlook it and continue spouting their tinfoil hat theories that Word is faster than Open Office because of some secret Microsoft dirty tricks.
There's a difference between "Free Software" and "Open Source".
And despite what the zealots may say, there's plenty of room for both in the world.
I just reverted some pages on my watch list on Wikipedia that had been edited with a google spam bot to link all sorts of words back to its mother site....
It's too bad it stays around in Wikipedia's history pages --- meaning the spammer is still getting full value from their links.
RIAA asked for it. They got it...
The RIAA can have my fingerprints when they pry them from my cold, dead hands.
THIS NOTE IS LEGAL TENDER FOR ALL DEBTS PUBLIC AND PRIVATE.
It's not a debt until you've bought it. Before then, anything goes.
Thanks to GameSpy for its 'Pixel' column discussing whether the early days of the PlayStation and Saturn are a newer, but nevertheless interesting stage of 'retro'.
They're not retro yet if people still actually use them. I know people that still play games on their original PlayStation.
Give them another 10 years or so. Nothing picks up speed as being "retro" until the people who grew up with it get to the point where they have the capability of enabling their want for nostalgia.
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
.NET fixes this problem by deprecating use of the registry, preferring systemwide configuration for an application to be in the application's directory, and side-by-side DLL use. They even market the whole idea as enabling "XCOPY Deployment" (referring to the DOS utility XCOPY, which can copy a whole directory tree).
The only shared aspect it has is the GAC, which is really only intended to be used in special cases, not in a general application's use.
So why don't we speak of "Avi movies" instead of DivX movies?
I don't know about you, but I usually refer to them as "AVIs". I couldn't care less as to what sort of encoding is used inside, as long as it plays on my system.
You give me a million, I give you a million, and we both keep it as well.
Ok. You go first.
make their own virtual machine and bytecode, and then make mods to existing language compilers to complie to bytecode the OSS virtual machine can run
We've already got one, and it's built on ECMA standards too!
How in the world can you be split over something like that?
The fear of a fork is what keeps the community split. A truly open source Java would have no restrictions against someone taking Java and extending it in a way that's incompatible with existing Java (remember when Microsoft tried to do that?). It would completely undermine the idea of Java as a stable universally-compatible platform to build on.
So there is nothing preventing them from doing this. Are we are just hoping that they act like a grown-up, blue chip company?
.NET that would have benefited the most from patent protection, MSIL, which was very cleverly designed to JIT code as optimal as a native compiler would spit out from the same source (as opposed to say, Java's bytecode, which doesn't JIT very well at all due to the complexity of the opcodes, among other factors). The bulk of the Framework classes aren't really much more than a collection of well-known, pre-existing algorithms and concepts (there's not much patentable ground in regards to a String API, or a Stream API, etc.), so even if Microsoft did want to rattle the chains about Mono in that respect, they'd be fighting a weak stance -- they can't just intimidate Miguel de Icaza into giving up on Mono since Novell's got his back and enough money to stand up to Microsoft.
.NET into Windows itself. Longhorn will provide a managed API for everything, and the new features will only be exposed through managed APIs. Avalon and WinFX will make writing .NET apps even easier. They'll always be able to out-.NET Mono, but at the same time they'll reap the benefits of increased interoperability which they'll eventually try to use as leverage to get Windows into more server rooms -- the frontier that Windows is the minority in currently, and the only room for Microsoft to grow into.
Their legal commitment to their stockholders to keep their stock values as high as possible is preventing them from doing this. If Microsoft starts making acts of desperation, they'll be seen as a desperate company, and a desperate company's stock prices aren't as high as a well-off company.
While you could make the argument that that's no assurance they won't do it at all; I could point out that there's no assurance they wouldn't incite legal action against just about any open source project for any of the patents in their portfolio, since they have patents that cover just about everything.
And then there's also the fact that they gave up to ECMA what's arguably the part of
Where Microsoft is going to fight is on the integration with
That's why Microsoft's not going to take out Mono. That's why they're even plugging Mono on MSDN.
All of the above. The kernel of XP didn't get any additional bloat that would slow it down, and, as I mentioned, it's been improved in many ways over 2K. By turning the visual effects down to 2K levels, you'll get better than 2K performance. Disabling the visual styles, the menu fading animations, and, in my experience, most importantly, the drop shadows on menus and tooltips.
Surely it should be RPN Calculators Future of the
Well, more accurately it should be "Calcuators RPN Future the of", but if I were to point that out I'd be basically admitting how much of a geek I am.
I could see "Unix for people who have no clue about Unix".
Me too, if they were paid by the word. But they're not. They were going for a shorty, catchy, memorable title; and the first book in the series was "DOS for Dummies", so it was a little alliteration as well.
What is going to prevent Microsoft from playing the patent card when it suits them?
Microsoft has never used a patent in that manner. Nor do most companies, actually -- patent portfolios are built more for defense than for offense. Making money out of patent litigation is something that fly-by-night vulture companies do, not blue chips like MSFT.
Second, Microsoft has much to lose themselves from shutting down Mono. They often point to Mono as an example of the flexibility and interoperability of their platform, and in fact they even have an interview with Miguel on MSDN to help convince developers of the same thing as well.
Microsoft would seriously have to be pinned against the ropes before they'd make such a desperate move. In fact, I'd be willing to venture that they'd embrace Linux wholeheartedly out of desperation before they'd resort to using patents in that manner.
are the relevant ECMA standards 334 and 335 and just RAND, or are they really RAND and royalty free as miguel and others have claimed?
The standards are royalty free, however the standards only cover the CLR (the VM/JIT) and C# the language, not the Framework (all the classes that do stuff).
That's partially why the Mono folks are making two stacks -- the Microsoft-compatible stack, which may be patent encumbered (though Microsoft has never yet used a patent offensively); and the Mono stack, which isn't chained to Microsoft, and better supports Linux anyhow.
Mono is fairly efficient, but there is a lot of room to grow optimization wise.
The Slashdot crowd might be interested to know that recently on the mono-devel list there have been benchmarks and discussions on moving the implemention of Mono's System.String class from native code to managed code since Mono's JIT actually already provides better performance than the native code does in that case.
Though the performance increase (which is 50% in one case!) can be mostly attributed to no longer having to go between managed/native code, that a pure managed solution is faster is impressive on its own regardless.
upgrading from 2K to XP on the same hardware will slow you down.
Unless you turn off the eye candy, in which case XP is measurably faster than 2K, since XP includes reordering and prelinking routines to reduce disk seeking time and relocation time during startup.
the XP booting issue isn't a distro issue but a kernel issue, and the problem was created by MS, not Linus
Bullshit . The problem does not exist if you install FC1 on the same system. Something in Linux changes that breaks system and it's Microsoft's fault? Even if Microsoft is creating an incorrect partition table, previous releases of the Linux kernel supported it just fine, thank you very much. This new behavior is a regression in Linux.
We have here a virus for IA64, a system that's out there in a minimal amount of machines, all high-end (presumably well-protected) servers. Now one of the standard explanations for the lack of viruses for Linux is that Linux is not as widespread. It is, however, much more widespread than IA64. Thus the amount of Linuxen out there is certainly not the only reason we're not seeing virues for Linux. Who knows, maybe Linux *is* actually more secure than Windows?
You act as if there've never been any worms or viruses for Linux...
I don't run linux personally.. but the lack of choice is annoying. I paid for XP pro and I should be able to remove components completely.
Sure you can hack up your copy of XP Pro to try to remove IE entirely. Some people do. But you mentioned yourself, IE is not just a web browser. It provides critical services to almost every application you'd want to run under Windows. Despite all the Slashbot sneering and jeering about the issue, it really is an integral part of Windows, and removing it makes the system about as useful as removing the network stack from Linux.
If your idealism is strong enough that you can't stand IE being used as a library for internet access, or as a layout engine for applications (both uses, I might add, that Mozilla can't just be plugged in as a replacement to fill due to it not being IE-compatible), then your only real solution is to throw the baby out with the bathwater and not use Windows.
Besides the fact that Mozilla was the first on the scene to include an option to block out pop-ups (I haven't bother to check has IE included that option yet?) that alone should be a reason for people to download a separate browser.
That's not a good reason. "Getting there first" doesn't count for beans in software. Case in point, IE was the first on the scene with dynamic reflow and any sort of CSS support, but I doubt you'd point to that as a good enough reason alone for people to use IE today.
If you want popup blocking with IE, you can easily download the Google Toolbar, which is a much smaller and easier download and install than Mozilla -- with less compatibility issues. Or you can wait a month or two until XP SP2 comes out, which builds the functionality right into IE.