Problems running wine.
Hi all.
I have been trying to get the CVS version of wine up
and running but I am having no luck. When I try to
run my program under wine, I get an error like this:
trace:heap:HeapAlloc (4041,0002,0018): returning 40413414
warn:thread:THREAD_InitStack Thread stack size is 32 MB.
trace:virtual:VirtualAlloc 02027000 1000 0040
0805f458: terminate_process( handle=-1, exit_code=14 )
0805f458: terminate_process() = 0 { self=1 }
0805f458: *killed* exit_code=14
/home/mo/.wine/user.reg: saving key USER\\mo
/home/mo/.wine/system.reg: saving key MACHINE
mo(/mnt/image/win_root/Tcl_Xmingw/bin)% /home/mo/.wine/userdef.reg:
saving key USER\\.Default
/home/mo/.wine/wine.userreg: saving key USER
I figured that was a memory problem so I added some
more swap space and ran it again, that seemed to work
a little better, but it broke like so:
trace:heap:HeapFree (4041,0002,40423f24): returning TRUE
trace:heap:HeapFree (4041,0002,40423f00): returning TRUE
trace:module:MODULE_InitDLL (0x40423e6c,PROCESS_DETACH,0x1) - RETURN 1
trace:module:MODULE_InitDLL (KERNEL32.dll,PROCESS_DETACH,0x1) - CALL
trace:relay:PE_InitDLL
CallTo32(entryproc=0x4057916c,module=40574000,type=0,res=0x1)
trace:module:MODULE_InitDLL (0x40411fec,PROCESS_DETACH,0x1) - RETURN 1
trace:module:MODULE_InitDLL (ntdll.dll,PROCESS_DETACH,0x1) - CALL
trace:module:MODULE_InitDLL (0x40412150,PROCESS_DETACH,0x1) - RETURN 1
0805f458: terminate_process( handle=-1, exit_code=0 )
0877d5a0: *killed* exit_code=0
0805f458: terminate_process() = 0 { self=1 }
0805f458: *killed* exit_code=0
Does anyone know what is going one here?
I am trying to test out code that I created using mingw
to cross compile windows applications under Linux. I
do not need to test everything, I just want to run
the thing in wine as a sanity check for the compiler.
If wine really works well, I may end up running regression tests
for the windows application under wine. That would
be cool because I would not need to boot into windows.
This could also be a really good way to test out wine
itself. I will post more on that later if I get it working.
thanks
Mo DeJong
Red Hat Inc
Re: Link windows NT .lib
Hello ! On Tue, Jul 11, 2000 at 09:23:28AM +0200, [EMAIL PROTECTED] wrote: Not exactly. YES, exactly. At least according to your description below. I got a chli.lib (NT) , a chli.h , a chli.dll (NT) and the API documentation. I used to link the lib to my C programs with MSVC under NT. I'm wondering how to link the lib file with GCC under Linux so calls to the DLL work under Linux. This is EXACTLY what Winelib is supposed to do. Again, read HOWTO-Winelib. Andreas Mohr
Re: Link windows NT .lib
On Tue, 11 Jul 2000, Andreas Mohr wrote: On Tue, Jul 11, 2000 at 09:23:28AM +0200, [EMAIL PROTECTED] wrote: I got a chli.lib (NT) , a chli.h , a chli.dll (NT) and the API documentation. I used to link the lib to my C programs with MSVC under NT. I'm wondering how to link the lib file with GCC under Linux so calls to the DLL work under Linux. This is EXACTLY what Winelib is supposed to do. Perhaps Winelib could use a "wine-implib" tool or something... or is such a tool already in the dllglue stuff that's part of the coveted elfdlls?
Re: HOWTO-winelib update
On Mon, 10 Jul 2000, John R . Sheets wrote: [snip] My personal take is that none of the above files should be included. After all, the WineLib examples are targeted for developers, who should be able to install autoconf and libtool (and automake?). They are usually installed as part of a development environment anyways. John OK. Thanks for the info. It is certainly not my intention to commit files needlessly. I am new to automake, autoconf, and friends and I am still reading the fine manual. I withdraw my patch and will try again next week. -- Wilbur Dale Lumin Software BV Zandheuvel 52 B 4901 HW Oosterhout (NB) The Netherlands phone: +31-(0)162-47.88.42 fax: +31-(0)162-43.31.52
RE: Link windows NT .lib
Not exactly. I got a chli.lib (NT) , a chli.h , a chli.dll (NT) and the API documentation. I used to link the lib to my C programs with MSVC under NT. I'm wondering how to link the lib file with GCC under Linux so calls to the DLL work under Linux. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 10, 2000 20:22 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Link windows NT .lib On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote: Hi, Sorry to ask for a maybe off-topic subject but : I got an old Windows NT 3.5 apps which runs fine (perfect but no shell commands i.e. I can't do a !dir ). It was provided with a binary lib file (MSVC) , the header file and the API documention to wite C programs to perform specific tasks faster than with what they called procedure files. I was wondering if I could drop NT platform to use Linux with Wine. The only point left without an answer is how to link the MS lib with GCC under Linux. This sound to me to be a GCC question but I couldn't find any information in the GCC How-to and as the application works fine with Wine, I'm trying in the wine-devel list. Thanks. Let's see if I understand what you are asking. You want to write c code that calls fuctions in MSVC.DLL and compile it with gcc? The way I know to do that is to write the c code as a winelib program. It would get at the dll with LoadLirary and GetProcAddress. There is a HOWTO-winelib in winedocumetation. Lawson ---cut here YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Re: Civ 2
On Mon, 10 Jul 2000, Brad Pepers wrote: Well in my continued quest to get Civilization 2 working on Linux and Wine, I thought I'd ask some questions on the latest debug output I've got. I've noticed that Civ2 as its dieing is trying to post an error message box and I also noticed that at around the point where all goes wrong, I had my own set of wars with Civ2 and I have no solutions, but Im interested in knowing if you used the inbuilt wine WinG or the external windows dll. In either case I had an unimplemented "BITMAP_GetObject16" message with a length of 74 or thereabouts. Id pretty much imagine that all bets are off after this point. I did make a fair stab at implementing this but still couldn't get any progress. C. Real Life: Caolan McNamara * Mobile: +49-177-2938135 Work: [EMAIL PROTECTED] * Work Ph.: +49-40-23646-672 URL: http://www.csn.ul.ie/~caolan * Sig: an oblique strategy Tidy up
Re: Link windows NT .lib
Ove Kaaven wrote: I'm wondering how to link the lib file with GCC under Linux so calls to the DLL work under Linux. This is EXACTLY what Winelib is supposed to do. Perhaps Winelib could use a "wine-implib" tool or something... or is such a tool already in the dllglue stuff that's part of the coveted elfdlls? All you need is a .spec-file to specify the interface. Could be a stripped down one (like the .def-files on windows). You cannot use .lib-files because there format is not understood by the gnu toolchain. However, someone could make a conversion utility from .lib to .spec... Greetings Bertho
Re: Link windows NT .lib
On Mon, 10 Jul 2000, [EMAIL PROTECTED] wrote: On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote: [snip] I was wondering if I could drop NT platform to use Linux with Wine. The only point left without an answer is how to link the MS lib with GCC under Linux. [snip] [snip] Let's see if I understand what you are asking. You want to write c code that calls fuctions in MSVC.DLL and compile it with gcc? The way I know to do that is to write the c code as a winelib program. It would get at the dll with LoadLirary and GetProcAddress. There is a HOWTO-winelib in winedocumetation. Unfortunately, the part of HOWTO-winelib on DLLs is still incomplete. I submited a patch yesterday, but there were some (legitimate) objections to the size of the files I submitted as examples. I withdrew the patch this morning. Also, you refer to the library as .lib in the subject line. Is this a static library? I don't know of any way to link a static library into WineLib. Depending on how the library is to interact with your application, you may be able to wrap the static library into a dynamic library and use WineLib. If you don't mind large emails, send me a private email and I can give you the examples and the most recent version of the HOWTO-winelib. -- Wilbur Dale Lumin Software BV Zandheuvel 52 B 4901 HW Oosterhout (NB) The Netherlands phone: +31-(0)162-47.88.42 fax: +31-(0)162-43.31.52
RE: Link windows NT .lib
Here is what I got so far trying to link.
[atoch@linux00 code]$ gcc -lm -ldl -L/usr/src/wine/dlls -L. -L/usr/src/wine
-lwine -lncurses -lutil chli.dll test.o -o test
chli.dll: file not recognized: File format not recognized
collect2: ld returned 1 exit status
[atoch@linux00 code]$ gcc -lm -ldl -L/usr/src/wine/dlls -L. -L/usr/src/wine
-lwine
-lncurses -lutil chli.lib test.o -o test
test.o: In function `main':
test.o(.text+0x15): undefined reference to `cfmini'
collect2: ld returned 1 exit status
=== test.c
#include "hli.h"
int main(void)
{
int status = 0;
cfmini(status);
return status ;
}
-Original Message-
From: Wilbur N. Dale [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 11:09
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Link windows NT .lib
On Mon, 10 Jul 2000, [EMAIL PROTECTED] wrote:
On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote:
[snip]
I was wondering if I could drop NT platform to use Linux with Wine. The
only
point left without an answer is how to link the MS lib with GCC under
Linux.
[snip]
[snip]
Let's see if I understand what you are asking. You want to write c code
that calls fuctions in MSVC.DLL and compile it with gcc?
The way I know to do that is to write the c code as a winelib
program. It would get at the dll with LoadLirary and GetProcAddress.
There is a HOWTO-winelib in winedocumetation.
Unfortunately, the part of HOWTO-winelib on DLLs is still incomplete. I
submited a patch yesterday, but there were some (legitimate) objections to
the
size of the files I submitted as examples. I withdrew the patch this
morning.
Also, you refer to the library as .lib in the subject line.
Is this a static library? I don't know of any way to link a static library
into
WineLib. Depending on how the library is to interact with your application,
you
may be able to wrap the static library into a dynamic library and use
WineLib.
If you don't mind large emails, send me a private email and I can give you
the
examples and the most recent version of the HOWTO-winelib.
--
Wilbur Dale
Lumin Software BV
Zandheuvel 52 B
4901 HW Oosterhout (NB)
The Netherlands
phone: +31-(0)162-47.88.42
fax: +31-(0)162-43.31.52
Re: Link windows NT .lib
On Tue, 11 Jul 2000, Bertho Stultiens wrote: Ove Kaaven wrote: I'm wondering how to link the lib file with GCC under Linux so calls to the DLL work under Linux. This is EXACTLY what Winelib is supposed to do. Perhaps Winelib could use a "wine-implib" tool or something... or is such a tool already in the dllglue stuff that's part of the coveted elfdlls? All you need is a .spec-file to specify the interface. Could be a stripped down one (like the .def-files on windows). Eh? I thought .spec files were supposed to be used for *exporting* a DLL interface from ELF code... not to *import* a DLL interface from a Windows .DLL file?! An "implib" does the latter, you know, taking a .DLL file, and generating import stubs for each entry point the DLL exports, and making an import library (.lib) file out of it. Or for wine-implib, perhaps an .a or .o file? A simple version of wine-implib could just generate a LoadLibrary and a bunch of GetProcAddress calls or something.
RE: Link windows NT .lib
[EMAIL PROTECTED] writes: Here is what I got so far trying to link. Hallo, I too want to join the discussion... It still isn't said, what the library functions deliver. Do those library functions call other windows functions or not? If those functions are self sufficent, "all" you need to do is find a linker that understand the MSVC format and build a Linx executable. If these functions call other windows functions, you must check what these functions are. If these functions are easy to emulate, I would propose writing wrapper functions ( with WINAPI calling convention) transforming those functions into Unix Libc functions. Then again a linker understanding MSVC format is needed and you would link your code against the library and the wrapper. If the library functions need the full fledged Windows Api, I think Winelib won't buy you too much. As you don't have source, you can't compile an application for anything else then X86. So build a normal Windows executable and run with Wine or NT as you like. A winelib application has nearly the same requirements as a windows application running under Wine. But again I understand that a linker understanding MSVC libraries and running under Unix/Linux would be welcome. Perhaps dlltools from the cygwin/mingw toolchain may help or implib, but I don't know. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: Link windows NT .lib
The library is self sufficient. Anyone knowing a linker able to link NT DLL to a Linux glib2.1 executable ? -Original Message- From: Uwe Bonnes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 11, 2000 14:40 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Link windows NT .lib [EMAIL PROTECTED] writes: Here is what I got so far trying to link. Hallo, I too want to join the discussion... It still isn't said, what the library functions deliver. Do those library functions call other windows functions or not? If those functions are self sufficent, "all" you need to do is find a linker that understand the MSVC format and build a Linx executable. If these functions call other windows functions, you must check what these functions are. If these functions are easy to emulate, I would propose writing wrapper functions ( with WINAPI calling convention) transforming those functions into Unix Libc functions. Then again a linker understanding MSVC format is needed and you would link your code against the library and the wrapper. If the library functions need the full fledged Windows Api, I think Winelib won't buy you too much. As you don't have source, you can't compile an application for anything else then X86. So build a normal Windows executable and run with Wine or NT as you like. A winelib application has nearly the same requirements as a windows application running under Wine. But again I understand that a linker understanding MSVC libraries and running under Unix/Linux would be welcome. Perhaps dlltools from the cygwin/mingw toolchain may help or implib, but I don't know. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: Link windows NT .lib
[EMAIL PROTECTED] writes: The library is self sufficient. Anyone knowing a linker able to link NT DLL to a Linux glib2.1 executable ? Perhaps ask on the Mingw (http://www.eGroups.com/messages/mingw32/) and cygwin mailing list too. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: Link windows NT .lib
How do you proceed when wine call native DLLs like gdi32.dll ? How wine is linked so it nows how to call functions in gdi32.dll ? Couldn't I use the same for my linux program be able to call chli.dll exports ? -Original Message- From: Uwe Bonnes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 11, 2000 14:57 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Link windows NT .lib [EMAIL PROTECTED] writes: The library is self sufficient. Anyone knowing a linker able to link NT DLL to a Linux glib2.1 executable ? Perhaps ask on the Mingw (http://www.eGroups.com/messages/mingw32/) and cygwin mailing list too. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
RE: Link windows NT .lib
[EMAIL PROTECTED] writes: How do you proceed when wine call native DLLs like gdi32.dll ? How wine is linked so it nows how to call functions in gdi32.dll ? Couldn't I use the same for my linux program be able to call chli.dll exports ? Hallo, as you told in a previous posting, those dlls are self sufficent. This means for me that you don't need USER, GDI or such. If your user program doesn't use functions from these libraries neither, you don't have to link against them. Wine and winelib however has a complete Loader facility that it can resolve DLL calls. That way a windows executable running in wine or a winelib executable has the abbility to resolve external references. But to use that loader, you need "full-fledged" wine. As you now talk about chli.dll, I think those .lib file you talk about are only stubs into that dlls and not static libraries and you will need full fledged Wine/Winelib capabilities. B.t.w.: Wine can't use native gdi/kernel/user and other core dlls and reimplements them. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine.conf graphical front-end development
Hi Martin, A few ideas thrown in... 1. you can choose if you want to generate new or edit existing wine.conf file. Generating new wine.conf would have default value? The generated wine.conf should have comments in it... 2. choose a location of your wine.conf file hmmm... that depends of the installation directory, eg. you install it under /usr or /usr/local (...) IMHO, the default value should be /usr/local/etc since default install directory should be /usr/local this way we would get binaries in /usr/local/bin libraries in /usr/local/lib .conf file in /usr/local/etc Moreover, keep in mind each user can have a .winerc which overrides wine.conf value. The wizard could have a "site" mode, where you change settings in wine.conf (as root, typically) and a user mode where you can change only the .winerc settings. I would be possible to switch in site mode by prompting for root password... 4. where the windows/profile/temp directory is ([wine] section of wine.conf file) I haven't read the WINE Admin book but, if I were a sysadmin, I would setup WINE this way (keep in mind it's not a devel sandbox...) Sysadmins comments are welcomed here... $TEMP (%temp%, in Windows) being assigned to /tmp (/tmp being a different drive or partition) $PROFILE being assigned to $HOME/.wine and it's where we would store user.reg wine.conf, system.reg and other system wide settings in /usr/local/etc (or /usr/local/etc/wine) 4.5 default wine look ([tweak.layout] section) 5. you can choose if you want to answer more questions, or if it is enough and you want save it and finish configuration. if you choosed more questions: 6. dll load order 7. things like "managed windows" ([x11drv] section) 8. ports ([serialports] [parallelports] [spooler] sections) 9. registry ([registry] section) 10. complete screen, where you can see and edit everything Ultimate wine hacker dream feature... The editor screen splits in two. Upper pane is for wine.conf/.winerc editing. The bottom pane updates itself with information for each setting, as you cursor move from line to line (some OS/2 config.sys editors behaved like this) Cheers, Francois
Re: wine.conf graphical front-end development
hello petr! Now, it would be nice to find some way, how to make this utility "cross-desktop". What do I mean? Consider this: many people will use GNOME / KDE / Corel-desktop (How is it called?) or bare X with wine (and possibly something like "wine-desktop" ... maybe). I absolutelly think, the "wine.conf graphical front-end" for GNOME _should_ be a GNOME application (written using Gtk+ and gnome-libs), similary the KDE one should be written using Qt and the "bare wine" by using winelib. Now it would be nice not to "invent the wheel" for each desktop separately, but rather to create some "skeleton" for the app, with desktop specific addons, that would be possible to compile then separately for each desktop. i forgot to write in my previous mail, that i already started to develop it using tcl/tk with [incr tcl/itcr tk] extension. the final product will be distributed as a half-statically linked executable, which will not require tcl/tk installed on target machine, but will depend on libraries like libX11. i'm not sure if it will be "cross-desktop" enough... what do you think? We can maybe use some meta-configuration file, that would describe, what the wine.conf entries are (including help), that would be distributed with each wine version, making the configuration program up-to-date. i'm not sure what exactly you meant. if some new option will be added in future wine version, how should program decide, where to put them in graphical i-face and how to integrate them with "nice-look" goal in mind? it can work pretty well if (for example) new "window look" will be added (like "Win 2k")... did you mean something like that? And Yes, the "wine.conf configurator" is not the only program, that is desktop-dependant and would be nice to be developed somehow "centrally" for all wine-desktop combinations. Consider e.g. 1) help browser (or better: the possibility to view windows .hlp files using native help-browser of the current desktop); or 2) integrating the component-systems between wine the desktops; or 3) integrating "start menu" and "the desktop" between wine and the desktops (so that freshly installed program's entry will appear somwhere in the GNOME/KDE/whatever "start menu".) i absolutely agree. "wine.conf front-end" should be developed with these goals in mind. martin
Re: wine.conf graphical front-end development
hello francois! 1. you can choose if you want to generate new or edit existing wine.conf file. Generating new wine.conf would have default value? The generated wine.conf should have comments in it... right, i meant something like that 2. choose a location of your wine.conf file hmmm... that depends of the installation directory, eg. you install it under /usr or /usr/local (...) IMHO, the default value should be /usr/local/etc since default install directory should be /usr/local it will look on usual locations, (like /usr/local/etc/wine.conf, ~/.winerc ...) and will create list-box with some possibilities for you. also you can choose "other location" than suggested. this way we would get binaries in /usr/local/bin libraries in /usr/local/lib .conf file in /usr/local/etc Moreover, keep in mind each user can have a .winerc which overrides wine.conf value. The wizard could have a "site" mode, where you change settings in wine.conf (as root, typically) and a user mode where you can change only the .winerc settings. I would be possible to switch in site mode by prompting for root password... maybe...maybe it don't have to care about things like that. if you would like edit global wine.conf file, you must have write permission to that file. if you don't have, you will be noticed. Ultimate wine hacker dream feature... The editor screen splits in two. Upper pane is for wine.conf/.winerc editing. The bottom pane updates itself with information for each setting, as you cursor move from line to line (some OS/2 config.sys editors behaved like this) wow :-) what's written in bottom pane, for example? isn't it the same as comments in wine.conf file? martin
Re: Link windows NT .lib
Uwe Bonnes wrote:
[EMAIL PROTECTED] writes:
How do you proceed when wine call native DLLs like gdi32.dll ?
How wine is linked so it nows how to call functions in gdi32.dll ?
Couldn't I use the same for my linux program be able to call chli.dll
exports ?
from your small test program, what you need to do is
in a chli_imp.c file:
8--
#include "hli.h"
static HANDLE chli_handle = 0;
/* be sure prototype is correct. could be
int WINAPI cfmini(int*)
void cfmini(int*)
...
*/
int cfmini(int * p)
{
static void (*pcfmini)(int*) = 0;
if (!chli_handle) {
chli_handle = LoadLibrary("chli.dll");
if (!chli_handle) MESSSAGE("can't load lib\n");
}
if (!pcfmini) {
pcfmini = GetProcAddress(chli_handle, "cfmini");
if (!pcfmini) MESSSAGE("can't get proc address\n");
}
return (*pcfmini)(p);
}
8--
(the import tool produces the code automatically, and in a more efficient and reduced
way)
HTH
A+
--
---
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
WINE fix needed - $ paid
Anyone available/willing to do little snippets of quick-turnaround WINE contract work? Initially, I'd like to pay someone $US300 to write a technical analysis of what WINE lacks that keeps http://www.ldscatalog.com/sggifs/download/PafSetup.exe (both the setup program and the program it installs) from running under WINE, and what would be involved in getting the necessary pieces into the source that would make it run (without Windows having to be installed). The analysis should enumerate the steps taken to make the determinations (so I can vicariously dip my toe into WINE internals and tools). This would form the basis of a statement of work for getting PAF to run under Linux/WINE, and creating a Debian package for it. If you know of anyone that can/will do this work, please let me know. == Jim Freeman [EMAIL PROTECTED] Sovereign Software
DEADLOCK/ race conditition
Hi ppl I'm getting the deadlock with WaitForSingleObject() as described in the deadlock thread. The strange thing is that maybe 1 out of 10 times trying to run this app it actually gets further.Maybe theres some kind of race conditiion going on here? I've managed to log it as it gets further/deadlocks with -debugmsg+ relay. I've bzipped the logs and have them available at http://indigo.ie/~fowler/wine as combined the logs come to nearly 20k. log.deadlock.bz2 is where it hits the deadlock and log.bz2 is where it doesnt. The software in question is a game called "Incoming" by Rage. If you need any more info I will try my best to get better logs. regards, Colin Fowler
kernel security patch
This is a follow-up on the thread on cemw 'Wine with ASS won't run stripped binaries' (see below) With a 'kernel security patch', the default load address for modules seems to be moved to 11 address, to get the Wine modules in the way of the Win32 normal load address (40) and reportedly there is a very misleading message on relocation and stripped executables. I have the following questions for the Linux specialists out there. 1) what are the chances of this patch to become the default in some near future ? 2) what could be the best way to solve such problem : - if a PE module where preferred loadaddress = 0 gets an address below 40 hex, print a warning. - force the load address ? - other ? Gerard Here is a quote of the post of 'STiNG OF DEATH' on cemw : Yes, I found and fixed the problem. As opposed to being a complex memory problem, it was simply a case of me not R'ing the F'img manual... I had the kernel security patch installed that I was testing, and I was somehow working with a kernel with all the security options turned on. Part of the security patch is to reallocate stack space to prevent hackers playing with your executable stack space. I quote from the patch's diff file /* This decides where the kernel will search for a free chunk of vm * space during mmap's. */ +#if defined(CONFIG_SECURE_STACK) defined(CONFIG_BINFMT_ELF) +extern struct linux_binfmt elf_format; +#define TASK_UNMAPPED_BASE ( \ + current-binfmt == elf_format \ + !(current-flags PF_STACKEXEC) \ + ? 0x0011UL \ + : TASK_SIZE / 3 ) +#else #define TASK_UNMAPPED_BASE(TASK_SIZE / 3) +#endif In other words, if secure stack is enabled, the unmapped base is moved. This has the possiblity to break WINE and many other programs.
Re: wine.conf graphical front-end development
What will be the license of this tool ? How will it be distributed/maintained ? joketroll Why, GPL, of course. /troll/joke It will be released under the Wine license, and hopefully will be part of the mainline Wine tree.
Re: kernel security patch
gerard patel [EMAIL PROTECTED] writes: I have the following questions for the Linux specialists out there. 1) what are the chances of this patch to become the default in some near future ? Very small IMO. 2) what could be the best way to solve such problem : - if a PE module where preferred loadaddress = 0 gets an address below 40 hex, print a warning. - force the load address ? - other ? Print a more explicit error message and die. I don't think there is anything else we can do (except maybe linking Wine statically, but I don't think this is desirable...) -- Alexandre Julliard [EMAIL PROTECTED]
Debugging question for MathType
I am in the process of trying to get MathType for Windows 4.0 running under wine. Before the app displays, it seems to get caught in an infinite loop. Here are what I believe to be the relevant lines: ... Call advapi32.227: RegOpenKeyExA(8001,40f42d90 "Software\\Design Science\\DSMT4\\Config",,00020019,408568cc) ret=00468b11 fs=008f Ret advapi32.227: RegOpenKeyExA() retval= ret=00468b11 fs=008f Call advapi32.235: RegQueryValueExA(003c,004ac7c4 "AppLang",,408568bc,4085686c,408568b8) ret=00468b3f fs=008f Ret advapi32.235: RegQueryValueExA() retval= ret=00468b3f fs=008f Call advapi32.204: RegCloseKey(003c) ret=00468b57 fs=008f Ret advapi32.204: RegCloseKey() retval= ret=00468b57 fs=008f Call kernel32.425: GetUserDefaultLCID() ret=00468f66 fs=008f Ret kernel32.425: GetUserDefaultLCID() retval=0009 ret=00468f66 fs=008f Call kernel32.342: GetLocaleInfoA(0409,0003,4085677c,00ff) ret=004281c2 fs=008f Ret kernel32.342: GetLocaleInfoA() retval=0004 ret=004281c2 fs=008f Call kernel32.534: MultiByteToWideChar(,,4085677c "ENU",,40f42e10,0004) ret=004026bd fs=008f Ret kernel32.534: MultiByteToWideChar() retval=0004 ret=004026bd fs=008f Call kernel32.727: WideCharToMultiByte(,,40856898 L"ENU",,40f42ea0,0007,,) ret=004026dc fs=008f Ret kernel32.727: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(40f42190 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",40856618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f Call kernel32.333: GetFullPathNameA(40f42190 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",0104,40856758,408565dc) ret=00491049 fs=008f Ret kernel32.333: GetFullPathNameA() retval=002d ret=00491049 fs=008f Call kernel32.342: GetLocaleInfoA(0409,0003,4085677c,00ff) ret=004281c2 fs=008f Ret kernel32.342: GetLocaleInfoA() retval=0004 ret=004281c2 fs=008f Call kernel32.534: MultiByteToWideChar(,,4085677c "ENU",,40f42200,0004) ret=004026bd fs=008f Ret kernel32.534: MultiByteToWideChar() retval=0004 ret=004026bd fs=008f Call kernel32.727: WideCharToMultiByte(,,40856898 L"ENU",,40f42ea0,0007,,) ret=004026dc fs=008f Ret kernel32.727: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(40f42210 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",40856618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f Call kernel32.333: GetFullPathNameA(40f42210 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",0104,40856758,408565dc) ret=00491049 fs=008f Ret kernel32.333: GetFullPathNameA() retval=002d ret=00491049 fs=008f Call kernel32.342: GetLocaleInfoA(0809,0003,4085677c,00ff) ret=004281c2 fs=008f Ret kernel32.342: GetLocaleInfoA() retval=0004 ret=004281c2 fs=008f Call kernel32.534: MultiByteToWideChar(,,4085677c "ENG",,40f42280,0004) ret=004026bd fs=008f Ret kernel32.534: MultiByteToWideChar() retval=0004 ret=004026bd fs=008f Call kernel32.727: WideCharToMultiByte(,,40856898 L"ENG",,40f42ea0,0007,,) ret=004026dc fs=008f Ret kernel32.727: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(40f42290 "C:\\Program Files\\MathType\\Language\\MT4ENG.DLL",40856618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f Call kernel32.333: GetFullPathNameA(40f42290 "C:\\Program Files\\MathType\\Language\\MT4ENG.DLL",0104,40856758,408565dc) ret=00491049 fs=008f Ret kernel32.333: GetFullPathNameA() retval=002d ret=00491049 fs=008f Call kernel32.342: GetLocaleInfoA(0c09,0003,4085677c,00ff) ret=004281c2 fs=008f Ret kernel32.342: GetLocaleInfoA() retval=0004 ret=004281c2 fs=008f Call kernel32.534: MultiByteToWideChar(,,4085677c "ENA",,40f42300,0004) ret=004026bd fs=008f Ret kernel32.534: MultiByteToWideChar() retval=0004 ret=004026bd fs=008f Call kernel32.727: WideCharToMultiByte(,,40856898 L"ENA",,40f42ea0,0007,,) ret=004026dc fs=008f Ret kernel32.727: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(40f42310 "C:\\Program Files\\MathType\\Language\\MT4ENA.DLL",40856618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f Call kernel32.333: GetFullPathNameA(40f42310 "C:\\Program Files\\MathType\\Language\\MT4ENA.DLL",0104,40856758,408565dc) ret=00491049 fs=008f Ret kernel32.333: GetFullPathNameA() retval=002d ret=00491049 fs=008f Call kernel32.342: GetLocaleInfoA(1009,0003,4085677c,00ff) ret=004281c2 fs=008f Ret
Re: wine.conf graphical front-end development
On Mon, 10 Jul 2000, Martin Pilka wrote: i'm working on graphical front-end for wine.conf file. You're of course already aware of the existing (but abandoned) TkWine project, which it'd be nice to build on? Perhaps it'd also be nice if it was possible to use this in conjunction with tools/wineinstall.
Re: kernel security patch
On Tue, 11 Jul 2000, gerard patel wrote: I have the following questions for the Linux specialists out there. 1) what are the chances of this patch to become the default in some near future ? Slim if we complain? 2) what could be the best way to solve such problem : - if a PE module where preferred loadaddress = 0 gets an address below 40 hex, print a warning. I'd have thought the allocated address was above. It was the libc.so that occupied the address that the Windows app wanted. - force the load address ? Well, forcing a load of a windows binary into libc's mapping... I don't think so.
