OSNews

Re: "2005 07 is the last release I can get to run WinMX. WinMX is an old app, and not mission critical for anyone, but it's symptomatic of the sisyphean task the Wine devs face. It makes me leery of trusting Wine with important apps and yet at the same time I feel like standing up and cheering the devs."

Except in the case of P2P software there are alternatives such as Azureus, KTorrent, LimeWire, etc. I would rather Wine developers focus their resources and time on applications such as Premiere Pro 2.0 and ZBrush 2.0 where there is no Linux port offered by the developer.

Edited 2006-03-05 03:08

Also, sometimes the break is elsewhere. For example, WinRAR quit working with WINE due to increased checking in X11. WinRAR tries to open an offscreen bitmap to hold toolbar icons; it tries to make it huge in case the person (idiot) adds an insane number of icons to the toolbar, so it asks for a bitmap just under 33000 pixels wide. X11 only allows bitmaps to be 32767 wide since all coordinates in X11 are a 16bit word.

Now under old versions of X11, it never checked if the bitmap asked for was too large - it simply made it. New versions check the boundaries and fail if they are greater than 32767. So now when WinRAR tries allocate its bitmap, it fails causing WinRAR to fail where it used to work.

The WINE folks and the XOrg folks have been arguing over who needs to fix what. The XOrg folks think that the WINE folks should make some kind of work-around for huge bitmaps, and the WINE folks think the XOrg folks should allow bitmaps to be created at any size.

I've been following wine-devel for a while, and I think the consensus is that it is Wine's fault. Last I remember reading about it was a couple of months ago, and I don't think the fix ever went in.

Sounds to me like it's WinRAR's fault, but WINE's problem. What happens if I try to make a bitmap 99*10^99999x99*10^99999?

Sounds to me like it's WinRAR's fault, but WINE's problem. What happens if I try to make a bitmap 99*10^99999x99*10^99999?

It will fail on win32 as well - out of memory.

Here's the bug:

http://bugs.winehq.org/show_bug.cgi?id=3573

Here's the link to the last email about the patch:

http://www.winehq.org/pipermail/wine-devel/2005-November/042893.htm...

From the thread:

"This patch is a rewrite of the imagelist handling to not use a Nx1 grid, but a NxM grid with M definable in the source (currently 4)."

"What Wine saves to stream is not binary compatible with windows. To make it compatible it has to be 4xN bitmap."

Someone asked about the status of this back in February, but got no reply.

It's most definitely WINE's problem, that's the compatibility layer, not X11. 16bitness may be a limitation of X11, but it's not XOrg's duty to make it behave like GDI just because WINE wants them to do so; that's WINE's problem to solve.

Wine still has a lot of work. And, obviously, you're not a programmer.

This is old news... like 2 days old! I didn't post it here because I thought someone else would, earlier.

Still needs work... but getting better.

Isn't Quake 3 available native for linux? Though I don't have it my self, it's in Gentoo's portage.

Yes it is and I have the native linux version of Quake3 on cd. I believe you need pak files from the cd to play it native like that though.

The pk3 files are interchangeable between Windows and Linux. That was really quite helpful when id went the stubborn route and sold Quake 3 Linux separately in retail, because retailers would drop the cost of the Linux version to $5-10 while the Windows version remained at a much higher price-point.

Quake3 is available for linux, and even if it wasn't now, the Quake3 source has been GPLed and released since summer. (Of course you'd have to provide your own map paks from say your windows Q3 cd or the demo...)

Quake 3 has already a native linux version

Quake 3 has already a native linux version

Yes, but some Q3 derivatives like American McGee's Alice aren't available. I play it via WINE in Fedora Core.

While I'm not exactly sure why it seems there is a Windows version of Wine. It's currently at 0.9.8 but it's bound to be updated to 0.9.9
You can find it here:
http://sourceforge.net/project/showfiles.php?group_id=6241&package_...

That made me curious, so I had a look at the Wine FAQ:

"Part of the rationale for these projects is to find out areas where Wine portability is lacking. This is especially true of the ReactOS project which is a reimplementation of the Windows kernel and should thus be able to reuse most of Wine dlls.

Another reason for pursuing these projects is to be able to replace a single Windows dll with its Wine counterpart. Besides being a good test for the Wine dll, this lets us detect cases where we made incorrect assumptions about how the dlls interact."

So it's mainly for helping with Wine development, but there could be actual use cases as well.

With Wine you could install and try a program as a limited user, and without having to touch C:Program Files or the registry. You can even have multiple fake Windows installations. Wine incurs less overhead than a full virtual machine, and it doesn't require additional licenses.

And some programs might actually run faster on Wine, because Wine libraries might be implemented better than the originals.

Also, wine can run Windows XP apps that Windows 95 is unable to run (for various reasons). I can't tell if wine runs on older versions of Windows or not, but if it did, it would make this extremely useful!

-Mark

Interesting line of thought... Wine could revitalize old, broken Win apps for Windows...