wine users - Nov 2009 - Memory Limitations for WINE 1.1.33 under Mac OS Leopard

Dear WINE Forum Users:

I have built WINE 1.1.33 from source using the directions at posted at

http://wiki.winehq.org/MacOSX/Building

In particular I did the following:

./configure --disable-win16

make depend && make

Since I do not need any graphical libraries for the application that I wish to
run under WINE everything runs fine for me using this build procedure.

My questions is that with earlier version of WINE (such as 1.1.18 and 1.1.21)
when I did such a default compile, I was able to allocate up to 1520MB per
process.  Now using the same build procedure I can only allocate up to 1040MB
per process.  As my application (command line only with NO GUI components
whatsoever) requires the ability to allocate rather large amounts of memory and
the recent unstable WINE releases seems to be going in the wrong direction in
terms of this issue (I can allocate LESS rather than MORE), I was wondering if
there are some flags or options that would enable me to maximize the memory
allocation with the newer WINE releases (at the very least to get back to the
1520 that was possible with the earlier releases).

My Mac OS is 10.5.8.  Please let me know if any further information is required.

Thanks,

Thomas

tpatko wrote:
> My questions is that with earlier version of WINE (such as 1.1.18 and
1.1.21) when I did such a default compile, I was able to allocate up to 1520MB
per process.
Make sure your program is compiled with flag indicating it can support more then
2GB.

Wine can only allocate memory from lover 2GB address space for regular programs.
And that's the area used by Wine itself and all the system libraries.

Dear James:

Thank you for the offer to assist with this issue.  I have NOT filed an official
bug report with WINE bugzilla as I am training to ascertain the exact issues
involved.  I have not done regression testing before, so it would take me a bit
of time to review all of these materials.

I have indeed used Mike Kronenberg's WINE binary builds to run this Windows
program under Mac (you will see this in the documentation) although I have
tested it against numerous WINE builds from source as well.  Since there was no
improvement to build from source I simply recommended using the precompiled
binaries from Mike.

It is indeed possible to get  a copy of the Firefly program.  It is copyrighted
but available free of charge (see download link below).  You can download the
binary for Mac from the public download page but will need a password to unrar
them.  Actually if you just complete the registration e-mail form (included in
the quick shart guide) and just mention that you are working with Thomas Patko
(the lead developer is quite familiar with me).

http://classic.chem.msu.su/gran/gamess/macosx.html

We are also now testing the new 7.1.G binary for Mac now as well (last official
release it 7.1.F), and I can give you the download password and links to this
directly as soon as you are a registered PC GAMESS / Firefly user.

Thanks,

Thomas

DEAR WINE DEVELOPERS:

I have a question related to the lowering of the maximum memory allocation per
process from version 1.1.21 to 1.1.33 (described in this post).

Are there any plans to release WINE that includes support for 32/64-bit multilib
on Snow Leopard?  I believe that the Snow Leopard gcc compiler can now support
this time of build as well as the Snow Leopard OS itself.

There are now many Windows applications that could greatly take advantage of a
32/64-bit multilib builds (older Win32 API for graphical portions of programs
and 64-bit for computational and memory intensive back-end computing) and I
believe that there are very many Mac users that use WINE.

Your consideration and comments are appreciated to this related follow-up
question.

Thanks,

Thomas

Dear Alexandre:

Thank you for the response.  Well it seems that this particular bug (performance
reduction in memory allocation from 1.1.21 to 1.1.33) is a Mac specific issue as
best as I can tell.  Building the same 1.1.33 source code under CentOS 64-bit in
32-bit mode does not yield this reduction in memory allocation limits that I
have described.

For a variety of reasons it is not really possible to allocate this memory in
smaller chunks as you suggest (in fact for these type of programs it is actually
quite literally impossible).  In terms of OpenGL this is completely unnecessary
for my program to run through WINE.  The program is a console only application
(No GUI components whatsoever).  Is it possible to build the current version of
WINE (1.1.33 or newer) WITHOUT any OpenGL support and to help raise the memory
limit back to where it was in the 1.1.21 version (or higher) by freeing up this
memory that appears to be reserved for OpenGL in the Mac build.

Your thoughts and suggestions are appreciated.

Regards,

Thomas

Dear Alexandre:

Would the changing the memory sizes in loader/main.c to reserve more space for
WINE_DOS as you have recommended as be correct if my program is a Win32 console
application?  It is not actually a legacy DOS application but rather a very
modern Win32 console app (built with modern Intel Windows compilers) but without
any graphical components (which is why I asked about building WINE without any
graphical support).

Thanks,

Thomas

Dear WINE Developers and Users:

Thank you very much for your assistance about my question related to maximum
memory allocation for WINE 1.1.33 build under Mac OS X Leopard and Snow Leopard.
Indeed modification the __wine__dos variable in loader/main.c to a larger value
did exactly what my project required.  Using this modification I was able to
successfully allocate up to ~ 1838MB per process (using a real world parallel
8-core MPI test job for a total of 14,704MB in aggregate) when built under Snow
Leopard and up to ~ 1655MB per process when built under Leopard (also using this
same real world parallel 8-core MPI test job for a total of 13,240MB in
aggregate).  I just thought that I would report my results in case they are
useful for any other Mac users that need to use WINE for HPC type applications.

I do have two follow-up questions if you would be so kind as to assist me once
again:

1) How can I package the custom binary that were built with the modified
loader/main.c?  All I need is for this WINE binary to be portable for use on
other Mac Users machine.  I plan to distribute separate WINE binaries for
Leopard and Snow Leopard packages.  I just want to make sure that there are no
path of library dependency issues that I should be concerned with.

I know that I can do a "make install" but this will drop everything
into my /usr/local/bin directory.  I need to have all of the custom build WINE
binaries (and dependencies if necessary) drop into a single directory which I
can then include with my own Windows binaries and call to run my Windows
programs.  Is there an easy way to do this?  I know that there are way to build
WINE into a more robust application (as with Winebottler,...etc) but I do not
need anything this complex.  Since this WINE binary will be intended for use
ONLY with this one program, I just need all of the WINE binaries delivered into
a single directory without path or dependencies issue so that it the Windows
binary can be run on any user's machine simply by calling this WINE binary
to whatever location it will ultimately end up getting installed.

I hope that this request makes sense.  I suppose that I could just copy the
directory where I built WINE, but this directory is HUGE at over 400MB.  I would
like to make it as small as possible while ensuring that it still functions
properly.

2) Is there anything special that I need to do to comply with the WINE license
to distribute binary packages only?  I made ONLY the change to the __wine_dos
memory allocation variable (that is it).  Is it sufficient for me to document my
single change when redistributing binary package only or must all of the source
code be distributed as well.

Thank you for all of the assistance to date and I look forward to finishing this
project with your continued patience and help.

Cheers,

Thomas

Dear Gert:

Thank you for the reply.  There is no problem for me to make the modified source
available for download.  Thank you for the suggestions.  I will read the GPL and
LGPL before distribute the WINE binaries that I have built to ensure that I am
in compliance.

If anyone can assist with my question # 1 then I will be off an running :-)

1) How can I package the custom binary that were built with the modified
loader/main.c? All I need is for this WINE binary to be portable for use on
other Mac Users machine. I plan to distribute separate WINE binaries for Leopard
and Snow Leopard packages. I just want to make sure that there are no path of
library dependency issues that I should be concerned with.

I know that I can do a "make install" but this will drop everything
into my /usr/local/bin directory. I need to have all of the custom build WINE
binaries (and dependencies if necessary) drop into a single directory which I
can then include with my own Windows binaries and call to run my Windows
programs. Is there an easy way to do this? I know that there are way to build
WINE into a more robust application (as with Winebottler,...etc) but I do not
need anything this complex. Since this WINE binary will be intended for use ONLY
with this one program, I just need all of the WINE binaries delivered into a
single directory without path or dependencies issue so that it the Windows
binary can be run on any user's machine simply by calling this WINE binary
to whatever location it will ultimately end up getting installed.

I hope that this request makes sense. I suppose that I could just copy the
directory where I built WINE, but this directory is HUGE at over 400MB. I would
like to make it as small as possible while ensuring that it still functions
properly.

Gert van den Berg wrote:
> On Mon, Dec 7, 2009 at 19:47, doh123 <wineforum-user at winehq.org>
wrote:
> 
> > and look at all the options you have... you can specify MANY things.
??I have no idea which all ones will suit your needs because I just don't
have enough information... you can put many many flags on a ./configure though.
??I'd recommend at minimum to set a prefix on it, and to do a "make
install" at the end to install to that prefix... something like this.
> > 
> > 
> > Code:
> > 
> > ./configure --prefix=/Applications/Wine --disable-win16
> > make depend
> > make
> > make install
> > 
> > this will make Wine build for, and install to running in
/Applications/Wine
> > There are also many other --without commands you can see o the help,
to build without things you don't need.
> > 
> 
> he wants to package it... So just installing it is probably not the
> best method. (configuring for a custom directory and the installing it
> might work though....) (--prefix=~/my_wine for example)
> (a 'make tarball' kind of command would have been handy...)

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...

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.

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

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

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.

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

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}:100:Unknown pseudo-op: .cfi_same_value
{standard input}:100: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

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
julliard at winehq.org