Either that, or we have gone back to 1984. I didn't know Orwell wrote non-fiction!
So what does this mean for email clients like Gmail that use SSL encryption? Are we going to be required by law to give the government all our passwords?
Don't forget that Microsoft still need to be backward compatible as much as possible. It is possible that MS rewrote the image handling code, but kept it compatible with the way Win3.1 handles images such that they share the issue.
Another possibility is that MS are keeping the Win3.1 binaries to run 3.1 applications, as 3.1 applications are 16-bit. Microsoft are known for (as can be seen by the huge WinSxS folder in Vista) for keeping older versions of their libraries around. For example, comctl32 is kept around for programs that display the classic look (you need to opt in for the themed look), and all of the d3d[8/9/10]x_[26/../39/..].dll files that populate your system.
Also (not being a developer at Microsoft), I don't know how extensive the rewrites are, I can only deduce this from what I read about from sources like Paul Thurott and wikipedia.
Also, the Wine test results at http://test.winehq.org/data/ give a good indication at this. Those indicate a large variance in behaviour between the versions of Windows, but also show similarity between some of them (e.g. 95 and 98).
The Wine team are busy fixing these so that the tests should pass on all platforms, therefore some of this variance is being lost. (NOTE: some of these problems are differences in platform setup.)
Of course FF3 is a major version upgrade. However, the code is an evolution of the previous version.
Windows 95 (and its children), Windows NT, Windows 2000 (I believe), and Vista (not sure about XP) were *major* changes. Not incremental improvements on the existing codebase, but extensive rewrites. This means that although they provide the same (or slightly different core API), they are not the same codeline.
Microsoft - with Vista, through Win7 - are using the same codebase. That does not mean that it will be a Vista SP2, hence the FF3 reference. What it means is that they don't have to rewrite core kernel APIs, which would slow them down when writing the new features. (Here, think of Netscape's rewrite of their browser).
For Win8, they may abandon the Vista codebase and use something like MinWin, or Midori, or whatever is currently in vogue.
The Vista codeline is what Windows 2008 is built on (it is Vista SP1 with additional server-orientated stuff). The Windows 7 codebase is built on top of this.
Also, from what I understand, MS aren't doing anything too drastic in the kernel.
With Vista as the foundation (which they rewrote a lot of, IIRC) they can make incremental, evolutionary improvements.
Take Firefox as an example: Mozilla didn't rewrite it when they were developing FF3; they cleaned up bits, for sure, and added new features, but it was a logical progression.
With the number of developers Microsoft has, they can do a lot of development work, so have the potential to add a lot to the Vista/2008 codebase.
The V8 code has a Malloced class that wraps malloc/free with an out-of-memory check and a PreallocatedStorage class that is keeping allocated memory and reusing an already allocated block if one exists that has been "freed".
This is in the chromium sources under src/v8/src/allocation.*.
Wine proper uses X. There is a darwine port that was originally for PowerPC, that now maps onto quartz (see http://wiki.winehq.org/MacOSX).
CrossOver has a Mac version that they helped out to write with the Darwine team. It looks like the code for the native quartz driver got merged into wine 0.9.56, but I don't know what it's current state is.
Or that the MSDN documentation for IDirect3DDevice9::SetMaterial (http://msdn.microsoft.com/en-us/library/bb174437(VS.85).aspx) says that it returns "D3DERR_INVALIDCALL if the pMaterial parameter is invalid." but the tests on Wine show that D3D9 crashes with SetMaterial(NULL), whereas the DirectDraw version (no longer available on MSDN) *does* return D3DERR_INVALIDCALL!
This is likely due to the game making GDI calls. GDI is painfully slow at the moment (although the people at CodeWeavers have this on their hit-list) because it is making a round-trip with the X server for every GDI call you make.
If you run the directx tests they run blisteringly fast on Wine, so I doubt that the D3DOpenGL translation is the issue.
And D3D is not emulated; the D3D calls are translated to (mapped onto) OpenGL calls. This is like using a library like MFC, WTL or Qt that wrap the Windows API into a higher-level API.
I like the demo concept from the casual games from companies like Oberon Media. You get 1 hour free, after which you need to buy the game. Purchasing the game gives you a registration key that (at least for Oberon Media) is unlimited at re-registering. This works very well, as it gives you enough time to decide if you like the game and is exactly the same as the retail version.
Not everyone is a developer, I agree. Likewise, not everyone is a graphical artist, musician, documentation writer or translator. A project is not just about the code, there are other areas to work on.
Even if you cannot contribute to any of the above, you can help out in other ways.
You can donate money to a project to help keep it running.
You can help by triaging bugs so that the developers spend their time on the ones that can be fixed (i.e. not the ones that say "foosoft does not work!").
You can test new versions of the software to find any bugs or regressions. This is especially important for core libraries like X11, Gtk, Qt/KDE and Wine. The only way to get the Nouveau driver for NVidia graphics cards to work is by having people willing to test it, report any bugs/data, and work with the handful of developers on the project.
It does not matter how much time and/or money you are willing to contribute. Contribute how much you can doing what you can.
But if you don't want to pay for a MS license, and need a Windows-only application (such as Photoshop), Wine - or CrossOver Office/Games - are your only real options. Also, Vista is slow as hell on VM, so your limited to XP and earlier. There goes your new DirectX 10 only game!
I'm not saying that Wine is perfect: it's not. However, if you look at how much progress has been made over the past few years - especially by Jeremy White and the CrossOver developers - Wine has gone from being unusable to being able to run a lot of applications. Generally, the older the application, the better the chance of it running in Wine.
Theming support currently only works for common controls and property sheets. Therefore, user32 controls like buttons and static text don't currently render properly. There are also several rendering glitches when using themes.
So at the moment, while there is theming support, it is not completed and needs additional work. Not to mention the changes made to theming on Vista.
Slashdot Mirror
Welcome to the new China.
Either that, or we have gone back to 1984. I didn't know Orwell wrote non-fiction!
So what does this mean for email clients like Gmail that use SSL encryption? Are we going to be required by law to give the government all our passwords?
Microsoft must have slimmed Vista down a lot then, as Vista takes somewhere between 10GB - 15GB!
Don't forget that Microsoft still need to be backward compatible as much as possible. It is possible that MS rewrote the image handling code, but kept it compatible with the way Win3.1 handles images such that they share the issue.
Another possibility is that MS are keeping the Win3.1 binaries to run 3.1 applications, as 3.1 applications are 16-bit. Microsoft are known for (as can be seen by the huge WinSxS folder in Vista) for keeping older versions of their libraries around. For example, comctl32 is kept around for programs that display the classic look (you need to opt in for the themed look), and all of the d3d[8/9/10]x_[26/../39/..].dll files that populate your system.
Also (not being a developer at Microsoft), I don't know how extensive the rewrites are, I can only deduce this from what I read about from sources like Paul Thurott and wikipedia.
Also, the Wine test results at http://test.winehq.org/data/ give a good indication at this. Those indicate a large variance in behaviour between the versions of Windows, but also show similarity between some of them (e.g. 95 and 98).
The Wine team are busy fixing these so that the tests should pass on all platforms, therefore some of this variance is being lost. (NOTE: some of these problems are differences in platform setup.)
That's why I specifically worded it that way :)
Of course FF3 is a major version upgrade. However, the code is an evolution of the previous version.
Windows 95 (and its children), Windows NT, Windows 2000 (I believe), and Vista (not sure about XP) were *major* changes. Not incremental improvements on the existing codebase, but extensive rewrites. This means that although they provide the same (or slightly different core API), they are not the same codeline.
Microsoft - with Vista, through Win7 - are using the same codebase. That does not mean that it will be a Vista SP2, hence the FF3 reference. What it means is that they don't have to rewrite core kernel APIs, which would slow them down when writing the new features. (Here, think of Netscape's rewrite of their browser).
For Win8, they may abandon the Vista codebase and use something like MinWin, or Midori, or whatever is currently in vogue.
The Vista codeline is what Windows 2008 is built on (it is Vista SP1 with additional server-orientated stuff). The Windows 7 codebase is built on top of this.
Also, from what I understand, MS aren't doing anything too drastic in the kernel.
With Vista as the foundation (which they rewrote a lot of, IIRC) they can make incremental, evolutionary improvements.
Take Firefox as an example: Mozilla didn't rewrite it when they were developing FF3; they cleaned up bits, for sure, and added new features, but it was a logical progression.
With the number of developers Microsoft has, they can do a lot of development work, so have the potential to add a lot to the Vista/2008 codebase.
There is: http://www.openmoko.com/.
The V8 code has a Malloced class that wraps malloc/free with an out-of-memory check and a PreallocatedStorage class that is keeping allocated memory and reusing an already allocated block if one exists that has been "freed".
This is in the chromium sources under src/v8/src/allocation.*.
Wine proper uses X. There is a darwine port that was originally for PowerPC, that now maps onto quartz (see http://wiki.winehq.org/MacOSX).
CrossOver has a Mac version that they helped out to write with the Darwine team. It looks like the code for the native quartz driver got merged into wine 0.9.56, but I don't know what it's current state is.
You would also need it the other way around, to support existing OpenGL applications running on the forked version.
This could also be done via a compatability layer, in the way that Wine is mapping DirectX to OpenGL.
And then there's Cairo for really sweet vector graphics, which also runs on everything.
And have you tried looking for documentation on Microsoft APIs that are over a year old? (Try the http://msdn.microsoft.com/en-us/library/bb153255(VS.85).aspx link to Microsoft.DirectX.DirectDraw)
Or that the MSDN documentation for IDirect3DDevice9::SetMaterial (http://msdn.microsoft.com/en-us/library/bb174437(VS.85).aspx) says that it returns "D3DERR_INVALIDCALL if the pMaterial parameter is invalid." but the tests on Wine show that D3D9 crashes with SetMaterial(NULL), whereas the DirectDraw version (no longer available on MSDN) *does* return D3DERR_INVALIDCALL!
This is likely due to the game making GDI calls. GDI is painfully slow at the moment (although the people at CodeWeavers have this on their hit-list) because it is making a round-trip with the X server for every GDI call you make.
If you run the directx tests they run blisteringly fast on Wine, so I doubt that the D3DOpenGL translation is the issue.
And D3D is not emulated; the D3D calls are translated to (mapped onto) OpenGL calls. This is like using a library like MFC, WTL or Qt that wrap the Windows API into a higher-level API.
I like the demo concept from the casual games from companies like Oberon Media. You get 1 hour free, after which you need to buy the game. Purchasing the game gives you a registration key that (at least for Oberon Media) is unlimited at re-registering. This works very well, as it gives you enough time to decide if you like the game and is exactly the same as the retail version.
Not everyone is a developer, I agree. Likewise, not everyone is a graphical artist, musician, documentation writer or translator. A project is not just about the code, there are other areas to work on.
Even if you cannot contribute to any of the above, you can help out in other ways.
You can donate money to a project to help keep it running.
You can help by triaging bugs so that the developers spend their time on the ones that can be fixed (i.e. not the ones that say "foosoft does not work!").
You can test new versions of the software to find any bugs or regressions. This is especially important for core libraries like X11, Gtk, Qt/KDE and Wine. The only way to get the Nouveau driver for NVidia graphics cards to work is by having people willing to test it, report any bugs/data, and work with the handful of developers on the project.
It does not matter how much time and/or money you are willing to contribute. Contribute how much you can doing what you can.
But if you don't want to pay for a MS license, and need a Windows-only application (such as Photoshop), Wine - or CrossOver Office/Games - are your only real options. Also, Vista is slow as hell on VM, so your limited to XP and earlier. There goes your new DirectX 10 only game! I'm not saying that Wine is perfect: it's not. However, if you look at how much progress has been made over the past few years - especially by Jeremy White and the CrossOver developers - Wine has gone from being unusable to being able to run a lot of applications. Generally, the older the application, the better the chance of it running in Wine.
Theming support currently only works for common controls and property sheets. Therefore, user32 controls like buttons and static text don't currently render properly. There are also several rendering glitches when using themes. So at the moment, while there is theming support, it is not completed and needs additional work. Not to mention the changes made to theming on Vista.