November 2002 - Wine-Devel - list.winehq.org

Re: Fwd: Re: [putty]Winelib support + patch

by Francois Gouget

`On Fri, 29 Nov 2002, Dimitrie O. Paun wrote: > On November 25, 2002 05:39 pm, Francois Gouget wrote: > > However there is no wrapper involved in the above. if you have a > > wrapper, then the load sequence is: wine loads mfcapp.exe.so which is > > the wrapper, and then mfcapp.exe.so then loads mfcapp.dll.so which > > contains the actual application. > > But we have a wrapper already, why do we need two of them? It seems to > me one should be enough, if we can instruct wine to load said libs > before loading the app, no? If you modify wine itself then you should be able to remove the wrapper. However, how will you instruct Wine to load just the right libraries? Note that Wine should not load extra libraries, especially not GDI and stuff, unless it's needed. So you need a way to instruct Wine to do that just for this application. You could do that by writting a wrapper script around Wine (hmm, a wrapper again, different level but still a wrapper), or by having Wine get that information from the .so without dlopening it. > > I say 'mfcapp' because it's a typical case where you need the arapper. > > The reason for this one is that because of C++ you need to link to the > > mfc library in the Unix sense (Winelib does not know how to import > > virtual table pointers because they are variables, not functions). But > > this causes MFC static initializers to run before the dlls it depends on > > have been loaded and initialized. > > Sorry, I have to admit: this linking, importing, etc. is all Chinese to me. > Is this ignorance of importing variables a limitation of Winelib that we > can fix (import libraries?), or is it something fundamentally unfixable? Linking in the unix sense is the act of doing 'gcc -lfoo'. Unix will take care of loading the library foo. Importing is the act of telling winebuild that you want to import a WineLib library, and the act of loading the library is done by Wine using dlopen just before calling the 'WinMain' of your application (i.e. it's done after all the libraries you link with 'in the Unix sense' have been loaded and initialized). For instance you 'import' gdi32, you don't link with it: you never use '-lgdi32' when compiling a WineLib application. However, you have to link with Unix libraries like opengl or curses and you cannot import them (because they don't have the required 'PE' information that winebuild adds in the .spec.c file). So how does it work when you call something like CreateFileA? My understanding of it is that winebuild creates a strampoline for it in the .spec.c file. Then at load time Wine does a dlsym on the appropriate symbol and sets the trampoline to point to the right address. Thus when you call CreateFileA, your code jumps to the trampoline which jumps to the actual CreaFileA implementation. But you cannot create trampolines for variables. When your code tries to access a variable it accesses a specific address. You cannot store a 'jmp' at that address to force it to read stuff from another address. To solve this problem it seems like we would need to replace all variable declarations with code that looks like '*get_variable()' which besides the compilation issues is impossible if the variable access is generated by the compiler itself which is what happens with class virtual tables. > BTW, can you please take a look here: > http://www.dssd.ca/wine/Winelib-Apps.html#visual-mingw > It seems I'm running in the same problem. > > The way I understand it though is a bit different (or so it seems to me): > -- wine calls PROCESS_InitWine (first thing it does in main()) > -- PROCESS_InitWine -> open_builtin_exe_file -> wine_dll_load_main_exe > -- wine_dll_load_main_exe -> dlopen_dll > So this one loads the .so, and this triggers the static initializers to > run, thus calling the statically constructed classes, right? And here > the problem happens. Why? Because the kernel & friends have not yet been > loaded? Yes, I believe the problem is that dlopening your application exe causes all the libraries it is linked with in the Unix sense to be loaded and initialized immediately. Then your exe's static initializers are run which registers with Wine the list of dlls that your application wants to load. So when the CCriticalSection constructor tries to call a Wine function it is likely that the corresponding library has not yet been loaded or initialized. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Nov. 29, 2002

Janitorial Projects

by Dimitrie O. Paun

Folks, I have updated the Janitorial section: http://www.dssd.ca/wine/Wine-Fun.html#janitorial with the list of cross calls from 32->16, and W->A. There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII. Any takers? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.

Nov. 29, 2002

Re: somebody help me identify this bug please

by Jeff Smith

Is it only characters with the acute accent? Is it that your are attempting this using 'dead key' entry on a Spanish keyboard? If this is the case, the problem may be in a recent correction to the Spanish keyboard layout. I will work on this some more when I get a chance, but hopefully someone else will find something sooner. -- Jeff S >From: "ezra daniel" <ezra_daniel(a)hotmail.com> > >Hello, > >At work I use Lotus Notes under Wine. > >I downloaded compiled and installed the new wine version 20021125 and I am >no longer able to type accecented valves, like á é í ó ú. > >Ñ can be typed though correctly. > >With the other version 20021031 I could type accented valves.In fact I went >back to using the older version and worked again so it is obvious it is a >problem in the new wine version. > >Though I am a newbie and know nothing of developing, but I would like to >submit the bug to the proper person so it fixes it back again but I dont >know which section of wine or person deals with this character typing >problem. > >Can anyone point me in the right direction? Thanks in advance. > >-daniel >http://www.debian-gnu.com _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Nov. 29, 2002

Re: Winapi_check warnings

by Dimitrie O. Paun

On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > Not really, you haven't run ./configure on that tree have you? > winapi_check assumes that this is done, but I can fix it if > it irritates you. Oh, I have separate src/build trees, and I was running it in the source tree. In fact, I _have_ to run it in the source tree, and then I get the errors... -- Dimi.

Nov. 29, 2002

RE: Winapi_check warnings

by Patrik Stridvall

> Hi Patrik, > > I get these hundreds of warnings about "config.h": [snip] > First of all, I think they are bogus. Not really, you haven't run ./configure on that tree have you? winapi_check assumes that this is done, but I can fix it if it irritates you. > Second, if I specify the > --cross-call-win32-win16 flag, I expect to see only the problems > I am asking for, no? Shouldn't we silence all other warnings, if > we ask for something in particular? There is a --none option. winapi_check --none --cross-call-win32-win16 It doesn't always work though. Beware. However I fixed --cross-call-win32-win16 to support with my last patch, since I assumed somebody would ask. I was right it seems. Presumably you want the --progress option on as well: winapi_check --none --progress --cross-call-win32-win16

Nov. 29, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

Nov. 29, 2002

Winapi_check warnings

by Dimitrie O. Paun

Hi Patrik, I get these hundreds of warnings about "config.h": [dimi(a)dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16 dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include controls/desktop.c: #include "config.h": file not found controls/desktop.c: #include "config.h" is not a local include controls/edit.c: #include "config.h": file not found controls/edit.c: #include "config.h" is not a local include controls/icontitle.c: #include "config.h": file not found controls/icontitle.c: #include "config.h" is not a local include controls/menu.c: #include "config.h": file not found controls/menu.c: #include "config.h" is not a local include dlls/advapi32/advapi.c: #include "config.h": file not found First of all, I think they are bogus. Second, if I specify the --cross-call-win32-win16 flag, I expect to see only the problems I am asking for, no? Shouldn't we silence all other warnings, if we ask for something in particular? -- Dimi.

Nov. 29, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

On November 29, 2002 01:03 pm, Patrik Stridvall wrote: > With your suggestion above we can, so I like it. :-) Yay!!! I guess the problem is that we the current setup we can not include wine specific headers without having *our* win32 headers in the include path. Bad. Cool thing (me thinks) about my proposal is that it doesn't complicate Winelib use at all. Right now apps need to have a -I$(prefix)/include/wine now that will change to -I$(prefix)/include/win32 The only thing I don't like in my proposal is the win32 name, namely the 32. I guess Win64 will go in the same namespace, as well as win16. This is confusing. What about winxx or even better winapi? > > plus a bunch of other things (like making it easy to use other > > headers for the Win32 API, etc). And best of all, it seems to > > be easily implementable, no? > > "mv" is your friend however the CVS versioning doesn't like it though... We don't have to move anything in the tree, just modify where we install stuff. Of course, this means that you will not be able to use your tree include files in all cases, but I think it's good as a start. -- Dimi.

Nov. 29, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> Alexandre, > > Patrik brought up the header location sometime ago, in this thread: > http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 > > At the time, I thought it is a bit premature, that we have other > things to do. Now I realize that this is one of those highly visible > external things, that would be a _lot_ better to fix before people > start using Winelib. Otherwise will piss people off when we change, > or we will not change because people are already using the headers. True. > Both versions are not good, and I think we can fix them now without > too much pain. > > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers > > It is simple (to understand & implement), clean, and pretty. > And I think it solved Patrik's problem (even if I can't quite > understand what the problem is from the first message :)), It not easy to mix different flavours of the Win32 headers because of include problems. The problem is that is you have since we include wine specific files like: #include "wine/debug.h" we need to have a include path like -I${prefix}/include However now since the Wine version of the standard Win32 header are in ${prefix}/include we get them included as well if we do -I${prefix}/include So if we do for example -I/opt/microsoft/windows/include we get header include collisions. Sure with GNU C on Linux (and presumably) on Windows we can fix that by specifing a correct include order. However with Microsoft C++ we can't do it in a portable way. With your suggestion above we can, so I like it. :-) > plus a bunch of other things (like making it easy to use other > headers for the Win32 API, etc). And best of all, it seems to > be easily implementable, no? "mv" is your friend however the CVS versioning doesn't like it though...

Nov. 29, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dimitrie O. Paun

On November 25, 2002 05:39 pm, Francois Gouget wrote: > However there is no wrapper involved in the above. if you have a > wrapper, then the load sequence is: wine loads mfcapp.exe.so which is > the wrapper, and then mfcapp.exe.so then loads mfcapp.dll.so which > contains the actual application. But we have a wrapper already, why do we need two of them? It seems to me one should be enough, if we can instruct wine to load said libs before loading the app, no? > I say 'mfcapp' because it's a typical case where you need the arapper. > The reason for this one is that because of C++ you need to link to the > mfc library in the Unix sense (Winelib does not know how to import > virtual table pointers because they are variables, not functions). But > this causes MFC static initializers to run before the dlls it depends on > have been loaded and initialized. Sorry, I have to admit: this linking, importing, etc. is all Chinese to me. Is this ignorance of importing variables a limitation of Winelib that we can fix (import libraries?), or is it something fundamentally unfixable? BTW, can you please take a look here: http://www.dssd.ca/wine/Winelib-Apps.html#visual-mingw It seems I'm running in the same problem. The way I understand it though is a bit different (or so it seems to me): -- wine calls PROCESS_InitWine (first thing it does in main()) -- PROCESS_InitWine -> open_builtin_exe_file -> wine_dll_load_main_exe -- wine_dll_load_main_exe -> dlopen_dll So this one loads the .so, and this triggers the static initializers to run, thus calling the statically constructed classes, right? And here the problem happens. Why? Because the kernel & friends have not yet been loaded? -- Dimi.

Nov. 29, 2002