November 2004 - Wine-devel - list.winehq.org

How to port c++ program to linux using winelib
by Jia L Wu 15 Nov '04

15 Nov '04

Hi, I have a win32 program written in C++. I am trying to port it to linux using winelib. The software contanis one exe file and several dll files. I would like to keep this structure when moving them to linux. That is, I still would like to generate several corresponding shared libraries (instead of statically linking all files together) in llinux and they will be loaded at the runtime. However using winelib tools(winemaker, configure, make) for shared library generation, I get unresolved symbols error. It seems that I have to write a spec file for each dll to import(and export) functions provide by other dlls. However, since they all written in c++ and what need to be imported can either be class or class method, and parameters can be class either. SO I don't know how to handle this in spec file. Beside each dll file exports many functions or classes. It would be tedious to write a lengthy spec file manually. My question is that if it is possible that linking is not invoked during shared library generation under wine (but during the runtime)? How should I do it? Thanks. Wu

4 8

"Software Engineering with Wine" tutorial
by Dan Kegel 15 Nov '04

15 Nov '04

I'm putting together a mini-lab course on "Software Engineering with Wine". So far, it only shows how to build wine and run the conformance test, and troubleshoot common problems (in particular, the ones that caused hundreds of test failures when I ran them a couple weeks ago). It's at http://kegel.com/wine/sweng/ Comments welcome. (In particular, are there any other test suite gotchas I should tell the students about?) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: Kernel 2.6.9
by Jerry Jenkins 15 Nov '04

15 Nov '04

Paul Rupe wrote: > On Friday November 12 2004 11:48 am, Michael Stefaniuc wrote: > > >>Btw. does wine crash only with Remedy or does winemine crash too? > > > Most apps (winemine included) are ok. When I get home I'll try to find a > downloadable app that reproduces the problem consistently. > > Usually wine just hangs until I kill -9 everything, but this time I managed > to get a stack trace. It looks like a recursive loop: > =>1 0x7759b155 cxx_frame_handler+0x401 in msvcrt (0x77927f90) > 2 0x7759b5c3 in msvcrt (+0xb5c3) (0x77927fb4) > 3 0x77ee7be1 __wine_call_from_32_regs+0xb5 in ntdll (0x7792831c) > 4 0x7759ac79 __CxxFrameHandler+0x5 in msvcrt (0x77928358) > 5 0x77ec63b8 EXC_RtlRaiseException+0x18c in ntdll (0x779283ec) > 6 0x77edf32b raise_segv_exception+0x2f in ntdll (0x77928408) > 7 0x77ee7c50 __wine_call_from_32_restore_regs+0x0 in ntdll (0x779287d4) > ... > 90 0x77edf32b raise_segv_exception+0x2f in ntdll (0x7792f7d8) > Frames 2-7 repeat all the way down to 90. This is after a 'make clean' and > a full rebuild of Wine, btw. > > Does increasing stack size help? For example: Index: dlls/kernel/process.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/process.c,v retrieving revision 1.80 diff -u -r1.80 process.c --- dlls/kernel/process.c 30 Oct 2004 02:11:33 -0000 1.80 +++ dlls/kernel/process.c 15 Nov 2004 11:36:47 -0000 @@ -1183,7 +1183,7 @@ set_library_wargv( __wine_main_argv ); if (!build_command_line( __wine_main_wargv )) goto error; - stack_size = RtlImageNtHeader(peb->ImageBaseAddress)->OptionalHeader.SizeOfStackReserve; + stack_size = 10 * 1024 * 1024; /* allocate main thread stack */ if (!THREAD_InitStack( NtCurrentTeb(), stack_size )) goto error; __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

Re: Last-chance deactivation of MDI Child before destruction
by Dmitry Timoshkov 15 Nov '04

15 Nov '04

"Zach Gorman" <zach(a)archetypeauction.com> wrote: > Changelog: > If, during destruction of an MDI child frame, the application > re-activates the window that is about to be destroyed, de-activate > it one last time. > > Background: > This resolves an obscure problem caused by a difference in Windows > and Wine behavior. I have an MDI MFC app in which one of the MDI > child frames forces itself to stay at the back of the Z-order by > responding to MDI Activate messages, and re-activating the old > window (yes I know this is nasty). When Wine tries to switch the > active MDI child during the active child's destruction, this causes > the about-to-be-destroyed window to become active again. Windows > will issue one last WM_MDIACTIVATE to deactivate the window that > will be destroyed in this case, but Wine won't. This patch corrects > that difference in behavior. What happens if that additional WM_MDIACTIVATE won't deactivate an MDI child either, or an app doesn't allow deactivation for some reason? Anyway, please add another MDI message test case showing what Windows does in that case because your change is not obvious at all. -- Dmitry.

2 1

Kernel 2.6.9 - Issue Found
by Jesse Allen 15 Nov '04

15 Nov '04

Hi, For the past two weeks I've been tracking an issue that I found with kernels greater than 2.6.8 / 2.6.8.1 and wine. Starting with kernel 2.6.9-rc1, Warcraft III copy protection would not work -- ie please insert disc. I found changes to the cdrom driver in rc1. Reversing them did not work. For a while I was lost to what could have changed. Then I had an idea: search for changes that could affect the way processes run. That led me to reverse changes related to ptrace, and I found a series of patches that break Warcraft III copy protection code. Patch 1: ptrace single-stepping fix Included in 2.6.9-rc1 By Davide Libenzi? http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.1803.144.55 This change includes a note that it could break debuggers. Reversing this change would allow War3 to work in rc1, but kernels greater than rc1 would still not work. Patch 2: make single-step into signal delivery stop in handler Included in 2.6.9-rc2 By Roland McGrath http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1832.59.196 The next patch may depend on patch #2 because it is a bug-fix based on 2. Patch 3: Fix PTRACE_CONT after single-step into signal delivery Also 2.6.9-rc2 By Roland McGrath http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1847 Reversing patches 1, 2, and 3 in kernels 2.6.9-rc2 and greater (through 2.6.10-rc1) will allow War3 to work. I tried 1 & 3 without 2, but it failed leading me to believe that 1 & 2 are required. I didn't try 1 & 2 alone because I think reversing 2 would require 3 reversed. All the patch changes seem to be on ptrace single-stepping. However, there is at least one ptrace single-stepping patch that seems to make no difference at all: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.70 There are other single-stepping patches for different non-i386 architectures but I have no idea on these because I don't run the others. They are meaningless for wine anyways. Now that I've identified a problem, I'm curious where else it's cropping up. Paul Rupe, could you try reversing these patches to see if this fixes your crashing problem? And how about those people having trouble with debugging? Then I guess the next step is to find out if this is a wine bug or not. If it's not, then it may be a kernel bug and we should report it to the kernel devs. Jesse

4 5

"Crystallography programs under Wine"
by Dan Kegel 15 Nov '04

15 Nov '04

I just ran into http://www.ccp14.ac.uk/solution/wine/ which lists about ten free Windows apps used for crystalography, and how to run them under Wine. I guess these deserve an appdb entry; they don't seem to have one yet. That page describes workarounds needed to run with Wine as of about three years ago. Things may have progressed since then. For instance, the "you must rename files to have lower case" workaround no longer seems neccessary for the INDX program. I wrote the maintainer about that, haven't heard back from him yet. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: taskmodal messagebox implementation, take 3
by Ivan Leo Puoti 14 Nov '04

14 Nov '04

> No problem. I'll give a lengthy reply in the hope it can help other folks > dealing with this sort of thing too. Well, your code works, and I've made it into a patch. I've also removed what I beleive is a useless if check from MSGBOX_OnInit(). Due to my lame webmail client you code arrived with no indentation, so in the future please attach any code you send to me. If you think the attached patch is OK I'll forward it to wine-patches. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

Re: [D3D] Some surfaces related fixes
by Christian Costa 14 Nov '04

14 Nov '04

Mike Hearn wrote: >On Sun, 14 Nov 2004 13:40:15 +0000, Christian Costa wrote: > > >>+ if ((pDDSD->dwFlags & DDSD_LPSURFACE) && (pDDSD->lpSurface == NULL)) { >>+ /* Frank Herbert's Dune specifies a null pointer for the surface, ignore the LPSURFACE field */ >>+ FIXME("Null surface pointer specified, ignore it!\n"); >>+ pDDSD->dwFlags &= ~DDSD_LPSURFACE; >>+ } >>+ >> >> > >Apps passing in bogus data should normally be a trace or warn at most, >unles there is actually something to fix here it doesn't make sense to use >a fixme as it'll inevitably get users asking about it .... > >thanks -mike > > > > > Your're right, Mike. :-) I will resend a patch for that. Thanks. Christian

1 0

Re: taskmodal messagebox implementation, take 3
by Juan Lang 14 Nov '04

14 Nov '04

Hi Ivan. --- Ivan Leo Puoti <puoti(a)inwind.it> wrote: > Please consider I'm no programming wiz and I'm learning as I go along. No problem. I'll give a lengthy reply in the hope it can help other folks dealing with this sort of thing too. > Now, I don't see how else I could get MSGBOX_EnumProc() to remember the > values > of those that now are static variables, apart from using the heap for > everything, that seems a bit inefficent as we know how much data we want > to > store, or global variables, do you think I should use global ones > instead? > If not suggestions are welcome. Globals are also not thread-safe. Generally for thread safety, I'd suggest the following: declare a structure that has all the data you want to modify in MSGBOX_EnumProc, something like: struct MsgBoxEnumProcParams { int pass; int counter1; int counter2; int heapcheck; HWND *handles; }; In MessageBoxIndirectW, create one of these and pass its address as the LPARAM value to EnumThreadWindows(). However, this ignores style issues. I have problems with names like "counter1" and "counter2"; they don't tell me what they mean. Also, I don't like the magic values 0, 1, 2, 3, 4 for the LPARAM value; at the least these should be symbolic constants. Pass 3 doesn't modify the parameters at all, so it really should get its own callback function. It looks like heapcheck's purpose is to see whether handles has in fact been allocated. You could instead make sure to set handles to NULL when it isn't allocated. Also, there's the possibility of a memory leak in pass 4. I'd suggest the caller should be responsible for memory allocation. With these suggestions, I've come up with the following changes. I haven't checked whether this code works (or even compiles), it's just my attempt at rewriting what you're trying to do: struct ThreadWindows { UINT numHandles; UINT handlesLen; HWND *handles; }; BOOL CALLBACK MSGBOX_CountDisabledThreadWindows(HWND hwnd, LPARAM lParam) { if (!lParam) return FALSE; if (!IsWindowEnabled(hwnd)) *(UINT *)lParam++; return TRUE; } BOOL CALLBACK MSGBOX_EnumDisabledThreadWindows(HWND hwnd, LPARAM lParam) { if (!lParam) return FALSE; if (!IsWindowEnabled(hwnd)) { struct ThreadWindows *threadWindows = (struct ThreadWindows *)lParam; if (threadWindows->numHandles < threadWindows->handlesLen) threadWindows->handles[threadWindows->numHandles++] = hwnd; } return TRUE; } INT WINAPI MessageBoxIndirectW( LPMSGBOXPARAMSW msgbox ) { LPVOID tmplate; HRSRC hRes; int ret; UINT i; struct ThreadWindows threadWindows = { 0, 0, 0 }; static const WCHAR msg_box_res_nameW[] = { 'M','S','G','B','O','X',0 }; if (!(hRes = FindResourceExW(user32_module, (LPWSTR)RT_DIALOG, msg_box_res_nameW, msgbox->dwLanguageId))) return 0; if (!(tmplate = (LPVOID)LoadResource(user32_module, hRes))) return 0; /*handle task modal message boxes*/ if ((msgbox->dwStyle & MB_TASKMODAL) && (msgbox->hwndOwner==NULL)) { EnumThreadWindows(GetCurrentThreadId(), MSGBOX_CountDisabledThreadWindows, (LPARAM)&threadWindows.numHandles); if (threadWindows.numHandles) { threadWindows.handles = (HWND *)HeapAlloc(GetProcessHeap(), 0, threadWindows.numHandles * sizeof(HWND)); if (threadWindows.handles) threadWindows.handlesLen = threadWindows.numHandles; threadWindows.numHandles = 0; } EnumThreadWindows(GetCurrentThreadId(), MSGBOX_EnumDisabledThreadWindows, (LPARAM)&threadWindows); for (i = 0; i < threadWindows.numHandles; i++) DIALOG_DisableOwner(threadWindows.handles[i]); } ret=DialogBoxIndirectParamW(msgbox->hInstance, tmplate, msgbox->hwndOwner, MSGBOX_DlgProc, (LPARAM)msgbox); if ((msgbox->dwStyle & MB_TASKMODAL) && (msgbox->hwndOwner==NULL)) { for (i = 0; i < threadWindows.numHandles; i++) DIALOG_EnableOwner(threadWindows.handles[i]); if (threadWindows.handles) HeapFree(GetProcessHeap(), 0, threadWindows.handles); } return ret; } The changes I've made: I've renamed counter1 and counter2 to numHandles and handlesLen. handlesLen is the allocated number of handles, while numHandles is the number of handles actually stored. (Your code already dealt with the possibility of their being different: well done!) I've also used handles as its own guard; if it's NULL, it's not allocated. Otherwise it is. Like I suggested, I pass a pointer as an LPARAM to the two EnumThreadWindows callback functions. It seems two calls to EnumThreadWindows were unnecessary, since we already knew the window handles, so I just iterate over the values in handles rather than calling EnumThreadWindows again. If I'm incorrect in my understanding, of course change it. And, the caller is always responsible for memory allocation and freeing. I think this is safer than having the callback function do it. > >Any reason you aren't using HeapAlloc instead? > As this heap is only used by MSGBOX_EnumProc(), is there any reason why > I should > use HeapAlloc? It's sometimes easier to debug memory problems with the Windows heaps than with the libc ones. --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

winzip 9 doesn't run under wine :-(
by Dan Kegel 14 Nov '04

14 Nov '04

While putting together a tutorial on how to contribute test cases to Wine (http://kegel.com/wine/sweng/) I noticed that the current version 9 of WinZip doesn't install under vanilla Wine; it aborts with the message WinZip was unable to locate a recent version of the Windows HTML help viewer, which is required to display WinZip help. ... Seems like a bit of a showstopper. What's the plan for addressing this? Is it a 0.9 feature? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 8