Memory Limitations for WINE 1.1.33 under Mac OS Leopard

James Mckenzie · Post by **James Mckenzie** » Mon Dec 07, 2009 7:13 pm

doh123 wrote:

except he can easily right click the Wine folder here and hit "compress" makes a transportable zip, throw it on any other Mac's
/Applications folder, double click the zip... and its there on the other machine...

Except 'make install' puts files in /usr/bin and /usr/lib, not in the /Applications folder with vanilla Wine. I'm hoping that is not what we are discussing here.

not totalyl sure there wont be permission problems though, which is why I like using things in .apps, they get special permissions,
helps make it more transportable.

Most files in /Applications are owned by root:bin or root:root and have read/execute permissions for other users.

if he wants a full install program, he can use the package maker that comes with Xcode, and make an installer from the install....

Will this allow a 'clean' de-installation of the program if the user does not want to keep it around?

James McKenzie

doh123 · Post by **doh123** » Mon Dec 07, 2009 7:37 pm

James Mckenzie wrote:doh123 wrote:
Except 'make install' puts files in /usr/bin and /usr/lib, not in the /Applications folder with vanilla Wine. I'm hoping that is not what we are discussing here.

which files? I install to a custom prefix all the time and move it computer to computer and use it.. never messed with anything in /usr/bin and /usr/lib... and Wine works fine.

James Mckenzie wrote: Most files in /Applications are owned by root:bin or root:root and have read/execute permissions for other users.

Some are root (macports does this...), most actually aren't. The folder is open for all users to read/write to, with full access.

James Mckenzie wrote: Will this allow a 'clean' de-installation of the program if the user does not want to keep it around?

if it installs like normal Mac apps to everything in a single folder in /Applications... yes, you just remove the folder.

tpatko · Post by **tpatko** » Mon Dec 07, 2009 7:39 pm

Dear James:

I have a question about the following:

except he can easily right click the Wine folder here and hit "compress" makes a transportable zip, throw it on any other Mac's
/Applications folder, double click the zip... and its there on the other machine...

Except 'make install' puts files in /usr/bin and /usr/lib, not in the /Applications folder with vanilla Wine. I'm hoping that is not what we are discussing here.

If the following sequence below will not work according to what you have said:

./configure --prefix=/Applications/Wine --disable-win16
make depend
make
make install

What build sequence / options will place the all of final executables to /Application/Wine for example?

Most files in /Applications are owned by root:bin or root:root and have read/execute permissions for other users.

OK. For me just having the executables somewhere within the /Applications folder would be fine. Actually I plan the final installation location to be /Applications/Firefly/Wine In my case forcing this path to be fixed for each user is also OK.

Thank you for your assistance!

--Thomas

tpatko · Post by **tpatko** » Sun Dec 13, 2009 7:09 pm

Dear WINE Developers (particularly those that test builds on Mac):

Thank you so very much for all of the assistance! It seems that my builds using your instructions worked quite nicely. I was able to ultimately build WINE 1.1.33 under both Leopard and Snow Leopard to support setting the __wine_dos memory variable (in loader/main.c) to 1920MB (with 1914MB per process addressable by programs). This was quite an improvement. There was excellent stability even when all of the memory was allocated (running at 99%+ load for all 8-cores with an MPI run on a dual quad with well over 13GB aggregate memory addressed running for multiple days). I am quite pleased with this result.

Ultimately I did this based upon the standard 1.1.33 source.

./configure --prefix=/Applications/Firefly/WINE --disable-win16
make depend
make
make install

with /Applications/Firefly/WINE being the location for the WINE build that was included with the Windows binary (which was contained at /Applications/Firefly). I did have to make separate build for Leopard (10.5.

and Snow Leopard (10.6.2) to achieve optimal performance under each OS.

My application would particularly benefit it there would be some possibility to have a 32/64-bit multilib build of WINE. I suspect that this would only be possible on Snow Leopard if at all. It is OK for me if this code is not yet stable (alpha) as I am game to test it to see if it will work for a Windows console only application. Are any any releases versions that contains configure/build flags that would support a 32/64-bit multilib build on Snow Leopard? If so I would be game to test this and work with any developer that are actively moving on this front.

Cheers,

Thomas

vitamin · Post by **vitamin** » Mon Dec 14, 2009 12:48 am

tpatko wrote:Are any any releases versions that contains configure/build flags that would support a 32/64-bit multilib build?

No, there isn't. Current Wine (and I mean the development head) can only run as 32-bit or 64-bit but not both. There are still lots of things missing for that.

tpatko · Post by **tpatko** » Mon Dec 14, 2009 10:22 am

Dear Vitamin:

As to you last reply:

No, there isn't. Current Wine (and I mean the development head) can only run as 32-bit or 64-bit but not both. There are still lots of things missing for that.

Does this mean that a pure 64-bit configure/build of WINE is not so far off for Snow Leopard and it is the multilib that seems rather far away?

--Thomas

vitamin · Post by **vitamin** » Tue Dec 15, 2009 2:06 am

tpatko wrote:Does this mean that a pure 64-bit configure/build of WINE is not so far off for Snow Leopard and it is the multilib that seems rather far away?

Why don't you try that yourself and let us know? I don't have mac nor do I care much about it.

The wine-64 is the same bad on all platforms. And 32 & 64-bit Wines do not coexist with each-other even on Linux.

James Mckenzie · Post by **James Mckenzie** » Tue Dec 15, 2009 9:32 am

vitamin wrote:

tpatko wrote:
Does this mean that a pure 64-bit configure/build of WINE is not so far off for Snow Leopard and it is the multilib that seems rather far away?
Why don't you try that yourself and let us know? I don't have mac nor do I care much about it.

I do and I'll chime in on this. 64 bit Wine on the Mac will NOT run 32 bit Windows programs at the present time from what I understand. Maybe the folks at MacPorts have more on this.

I do know that XCode 3.1 is broken bad enough that 16 bit program parts are not buildable on Leopard.

The wine-64 is the same bad on all platforms. And 32 & 64-bit Wines do not coexist with each-other even on >Linux.

64 bit Wine is broken on Linux as well, correct?

James McKenzie

tpatko · Post by **tpatko** » Tue Dec 15, 2009 9:51 am

Indeed I have tried to build WINE from source as follows:

./configure --disable-win16 --enable-win64 --verbose --without-freetype

The configure completes without errors but a number of warnings:

configure: libhal/libdbus 64-bit development files not found, no dynamic device support.
configure: libgnutls 64-bit development files not found, no schannel support.
configure: libsane 64-bit development files not found, scanners won't be supported.
configure: libgphoto2 64-bit development files not found, digital cameras won't be supported.
configure: liblcms 64-bit development files not found, Color Management won't be supported.
configure: libcapi20 64-bit development files not found, ISDN won't be supported.
configure: fontconfig 64-bit development files not found, fontconfig won't be supported.
configure: libgsm 64-bit development files not found, gsm 06.10 codec won't be supported.
configure: libmpg123 64-bit development files not found (or too old), mp3 codec won't be supported.

configure: WARNING: OpenGL development headers not found.
OpenGL and Direct3D won't be supported.

configure: WARNING: libxml2 64-bit development files not found, XML won't be supported.

configure: WARNING: libxslt 64-bit development files not found, xslt won't be supported.

configure: WARNING: libjpeg 64-bit development files not found, JPEG won't be supported.

configure: WARNING: libpng 64-bit development files not found, PNG won't be supported.

configure: Finished. Do 'make depend && make' to compile Wine.

When I try to actually build (make depend && make) I get stopped with the following message:

gcc -m64 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o interlocked.o interlocked.c
{standard input}:87:Unknown pseudo-op: .cfi_adjust_cfa_offset
{standard input}:87:Rest of line ignored. 1st junk character valued 56 (8).
{standard input}:88:Unknown pseudo-op: .cfi_rel_offset
{standard input}:88:Rest of line ignored. 1st junk character valued 37 (%).
{standard input}:99:Unknown pseudo-op: .cfi_adjust_cfa_offset
{standard input}:99:Rest of line ignored. 1st junk character valued 45 (-).
{standard input}

Unknown pseudo-op: .cfi_same_value
{standard input}

Rest of line ignored. 1st junk character valued 37 (%).
make[2]: *** [interlocked.o] Error 1
make[1]: *** [port] Error 2
make: *** [libs] Error 2

Any ideas? Do I need to boot into the 64-bit Snow Leopard kernel to build 64-bit WINE? In this case the gcc compiler is already 64-bit by default, although I am not sure about of the libraries that it requires. Unfortunately it seems on my particular Mac Pro 2,1 I am not sure if it is possible/supported to boot into the 64-bit kernel as I have a slightly older 32-bit EFI on this machine.

Do I just need to disable more parts of the build to get it to go?

Thanks,

Thomas

vitamin · Post by **vitamin** » Tue Dec 15, 2009 9:56 am

James Mckenzie wrote:64 bit Wine is broken on Linux as well, correct?

Lets say it's more broken then 32-bit Wine, especially some parts like mshtml that can't work without wine_gecko, which available as 32-bit only ATM.

Alexandre Julliard · Post by **Alexandre Julliard** » Tue Dec 15, 2009 10:17 am

James Mckenzie <[email protected]> writes:

vitamin wrote:
The wine-64 is the same bad on all platforms. And 32 & 64-bit Wines do not coexist with each-other even on >Linux.

64 bit Wine is broken on Linux as well, correct?

It's not quite perfect, but it's much better on Linux. 64-bit isn't
supported at all on Mac OS at the moment.

--
Alexandre Julliard
[email protected]

tpatko · Post by **tpatko** » Tue Dec 15, 2009 12:04 pm

Dear Alexandre:

Thank you for the definitive (but rather disappointing) NO. If 64-bit support should become available on Mac (presumably on no OS before Snow Leopard). It would seem that the minimum prerequisite is most likely gcc 4.4.X and running in the 64-bit kernel mode at least for the build. I suspect that you do not necessarily need to be running in the 64-bit kernel mode to run the binary once built (perhaps 32-bit kernel is OK for this???).

In any event, my application might be a good first test for a 64-bit WINE build on Mac as it is a high performance MPI console only application (no graphics) that can really push the memory limits and probe the implementation efficiencies.

Cheers,

Thomas

It's not quite perfect, but it's much better on Linux. 64-bit isn't
supported at all on Mac OS at the moment.

--
Alexandre Julliard
[email protected]

tpatko · Post by **tpatko** » Mon Jan 11, 2010 10:59 pm

Dear Wine developers and Users:

Is it possible on Mac OS builds of WINE to designate an alternate locations for the user configuration files? This is set by default to be /Users/$USER/.wine for all of the builds without using any special flags.

Is it possible to use some configure flags (or if necessary modify the source) to make the configuration files for my custom build of wine for example set to:

/Users/$USER/.customwine

This would be quite useful so as not to conflict with another WINE builds that might be on the user's system as my custom build of wine is really only meant for use with one particular application for which it has been optimized.

Any assistance would be appreciated.

Regards,

Thomas

ryan woodsmall · Post by **ryan woodsmall** » Mon Jan 11, 2010 11:05 pm

/Users/$USER/.customwine

You just described a separate Wine prefix. You can specify separate Wine prefixes by setting environment variables in a shell session:

export WINEPREFIX=${HOME}/.customwine
wine winecfg

This is already built into Wine. Having a runtime setting as opposed to a compile-time setting is much more flexible.

tpatko · Post by **tpatko** » Mon Jan 11, 2010 11:45 pm

Dear Ryan Woodsmall:

Thank you for the tip. Does the call to:

wine winecfg

then need to be run each time that a new WINE session is initiated to run my Windows program? I guess in the case that the wine configuration files are already present it will just not write them again I suppose.

This should work just fine for me as the application is launched with a Bourne shell script. Setting the WINEPREFIX for each program call is thus very easy.

Thanks,

Thomas

ryan woodsmall · Post by **ryan woodsmall** » Mon Jan 11, 2010 11:51 pm

Thank you for the tip. Does the call to:

wine winecfg

then need to be run each time that a new WINE session is initiated to run my Windows program?

The first call of "wine programname" will result in the custom WINEPREFIX, if set, being created on the fly. If it already exists, files will not be overwritten every time. If you start a newer version of Wine with a WINEPREFIX that contains older Wine files, some housekeeping will take place, but it shouldn't (generally) break anything.

doh123 · Post by **doh123** » Mon Jan 11, 2010 11:52 pm

wine winecfg was an example of running a program... it runs winecfg... you dont *have* to run it....

the export WINEPREFIX to wherever you want it is all you have to do before running the Wine command you want to run.

You can right simple shell scripts to do this for you... and launch the program you want.

If you want WINEPREFIX to always be in 1 other specific place all the time without typing it, you can add the export line to your ~/.bash_profile ... and every time a session starts.. or new terminal window... it will automatically set it for you.

tpatko · Post by **tpatko** » Sun Sep 26, 2010 8:48 am

I noticed in the loader/main.c that there seems to be some comment that it might be possible to set a build such that 3GB of memory can be allocated for a 32-bit process (through virtual memory mapping).

static void check_vmsplit( void *stack )
{
if (stack < (void *)0x80000000)
{
/* if the stack is below 0x80000000, assume we can safely try a munmap there */
if (munmap( (void *)0x80000000, 1 ) == -1 && errno == EINVAL)
fprintf( stderr,
"Warning: memory above 0x80000000 doesn't seem to be accessible.\n"
"Wine requires a 3G/1G user/kernel memory split to work properly.\n" );
}
}

If this is possible, are there some instructions on how to modify the source code and/or configuration after the build to support this? Lastly, are these modification possible when building on Macintosh?

Cheers,

Thomas

vitamin · Post by **vitamin** » Mon Sep 27, 2010 8:56 am

tpatko wrote:I noticed in the loader/main.c that there seems to be some comment that it might be possible to set a build such that 3GB of memory can be allocated for a 32-bit process (through virtual memory mapping).

Wine supports this as-is. All you need is an application compiled as large memory aware executable. Then Wine will let it allocate up-to 3GB per process (less all the libraries of course).

tpatko · Post by **tpatko** » Mon Sep 27, 2010 10:06 am

Wine supports this as-is. All you need is an application compiled as large memory aware executable. Then Wine will let it allocate up-to 3GB per process (less all the libraries of course).

Is this true even when built on Mac were the wine_dos variable is statically allocated before compiling? My application of interest is a 32-bit binary which is in fact large memory aware.

--Thomas

vitamin · Post by **vitamin** » Tue Sep 28, 2010 8:34 am

tpatko wrote:Is this true even when built on Mac were the wine_dos variable is statically allocated before compiling?

Don't know. Don't have Mac.