December 2005 - Wine-Devel - list.winehq.org

Re: Load Library failed

by Ananth M

The problem is due to the Dll Name UpperCase. It is solved , Thank you On 12/1/05, Ananth M <mekaananth(a)gmail.com> wrote: > > Hi All > I am having a Simple DLL that was developed and used by the Windows > Application. I am trying to port this windows DLL into linux to create the > .so file and want to use the same. > As metioned in the winedump tool, > I generated the spec file using the command > > winedump spec simple.dll > > and inserted the Stub DLL into wine tree as metioned in the > winedump README > > I am able to see the simple.dll.so file dlls directory. > I created the .def file using the winebuild in the dlls/SimpleDll > directory. > > When I try to load this dll using "LoadLibrary("Simple.dll")" I am > getting the "Module Notfound error". > > I tried the same function after loading the same .so file into > /usr/local/lib/wine also. > Still I am getting the same error. > > BTW: I am able to load the built-in dlls in wine without any > problem. > > Can any one through some ideas.... > > > > > > >

Dec. 1, 2005

Re: advpack: Handle dwFlags for DelNode with tests

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > + /* Generate a path with wildcard suitable for iterating */ > + if (CharPrevA(szFilename, szFilename + iLen) != "\\") > + { I don't think this means what you think it means ;-) -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2005

Re: Use struct instead of interface in forward declaration

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Changelog: > Use struct instead of interface in forward declaration. Why? -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2005

Re: [NDR] Implement NdrClientCall2 and NdrServerCall2

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > + "shrl $2, %ecx\n\t" /* divide by 4 */ > + "rep movsl\n\t" /* Copy dword blocks */ > + "movl %eax, %ecx\n\t" > + "andl $3, %ecx\n\t" /* modulus 4 */ > + "rep movsb\n\t" /* Copy remainder */ If the argument size is not a multiple of 4 you are in serious trouble... Instead of reinventing it I'd suggest copying the call_entry_point function from dlls/ntdll/relay.c, it will also get the stack alignment right (plus it saves ebp at the right place ;-) -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2005

Re: wine-devel Digest, Vol 4, Issue 151

by Alexandre Julliard

Brian Vincent <brian.vincent(a)gmail.com> writes: > On 11/30/05, Andrea Capiluppi <a.capiluppi(a)gmail.com> wrote: >> i'm involved in a study of the evolution of wine, based on its releases: so >> far i tried to collect what i could find on the web, but some of the earliest >> points i'm still missing: maybe somebody involved in the development of wine >> still has these oldest releases? >> >> i'll be glad to illustrate the research if (anybody) interested > > 1. Read documentation/ChangeLog.OLD > 2. Read old comp.emulators.ms-windows.wine posts for releases > 3. CVS contains releases dating back a long way I already mentioned this to Andrea, but it may interest others: the new git repository on WineHQ contains all the releases I have, going back to 1993. You can browse it at http://source.winehq.org/git, or see the GitWine page on the wiki for instructions on how to download it. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2005

reports are not well displayed

by Curro Amores

Hi im getting crazy cos my access 97 application do what it wants when it wants. I have some kind of reports. The thing is that when i want to display them, the fonts are not well displayed, they are separated and bigger. But other reports are well displayed. I have copied all the ttf file from my windows (windows 98 or windows xp?) and nothing is fixed. This is the output i get when i push my application button " Vew Report". trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin if somebody wants to see the snapshots, please tell me and i will email them i would like to know y somebody had the same problem thanks a lot!

Dec. 1, 2005

wineconsole crashes with curses backend

by Pavel Roskin

Hello, Eric and everybody! wineconsole crashes in WCCURSES_Refresh() when run without arguments. PRIVATE(data)->line is NULL in curses.c on line 354. Checking PRIVATE(data)->line fixes the problem. The breakage was introduced by revision 1.39 of wineconsole.c. Removing call to WINECON_GetServerConfig() fixes the crash. Although WINECON_GetServerConfig() gets data that is mostly irrelevant to the curses backend, the harmful part is setting data->cells. Commenting it out also helps (but the "user" backend stops working). I think setting data->cells doesn't belong to WINECON_GetServerConfig(). Since setting data->cell suppresses handling of CONSOLE_RENDERER_SB_RESIZE_EVENT, data->fnResizeScreenBuffer and data->fnComputePositions should be called explicitly. Below is the patch I think is most reasonable. Still, I'd like someone more knowledgeable to look at it. I moved the code under init_success outside the switch statement, as it was getting too long. --- wineconsole.c +++ wineconsole.c @@ -557,9 +557,6 @@ static BOOL WINECON_GetServerConfig(stru } SERVER_END_REQ; WINECON_DumpConfig("first cfg: ", &data->curcfg); - data->cells = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, - data->curcfg.sb_width * data->curcfg.sb_height * sizeof(CHAR_INFO)); - if (!data->cells) WINECON_Fatal("OOM\n"); return ret; } @@ -654,13 +651,9 @@ static struct inner_data* WINECON_Init(H switch ((*backend)(data)) { case init_success: - WINECON_GetServerConfig(data); - WINECON_SetConfig(data, &cfg); - data->curcfg.registry = cfg.registry; - WINECON_DumpConfig("fint", &data->curcfg); - return data; - case init_failed: break; + case init_failed: + goto error; case init_not_supported: if (backend == WCCURSES_InitBackend) { @@ -673,6 +666,17 @@ static struct inner_data* WINECON_Init(H break; } + WINECON_GetServerConfig(data); + data->cells = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + data->curcfg.sb_width * data->curcfg.sb_height * sizeof(CHAR_INFO)); + if (!data->cells) WINECON_Fatal("OOM\n"); + data->fnResizeScreenBuffer(data); + data->fnComputePositions(data); + WINECON_SetConfig(data, &cfg); + data->curcfg.registry = cfg.registry; + WINECON_DumpConfig("fint", &data->curcfg); + return data; + error: WINE_ERR("failed to init.\n"); -- Regards, Pavel Roskin

Dec. 1, 2005

Re: Dereferencing a pointer in winedbg

by Eric Pouech

> please point me to it? I've spent last hour or so trying to > find it. just a quicker one: does display /i $eax help here ? A+ -- Eric Pouech

Dec. 1, 2005

Load Library failed

by Ananth M

Hi All I am having a Simple DLL that was developed and used by the Windows Application. I am trying to port this windows DLL into linux to create the .so file and want to use the same. As metioned in the winedump tool, I generated the spec file using the command > winedump spec simple.dll and inserted the Stub DLL into wine tree as metioned in the winedump README I am able to see the simple.dll.so file dlls directory. I created the .def file using the winebuild in the dlls/SimpleDll directory. When I try to load this dll using "LoadLibrary("Simple.dll")" I am getting the "Module Notfound error". I tried the same function after loading the same .so file into /usr/local/lib/wine also. Still I am getting the same error. BTW: I am able to load the built-in dlls in wine without any problem. Can any one through some ideas....

Dec. 1, 2005

Re: Incompatible behavior of InvalidateRect/LB_SELITEMRANGE/SetCapture

by Dmitry Timoshkov

"Andreas Rosenberg" <sonix2003(a)ctf-z.de> wrote: > >From time to time I'm testing our application (IQ-FMEA) with Wine. > > Our GUI framework is checking the return codes of most API calls, > so several incompatibilities between Windows and Wine are detected > while many other programs simply ignore them. > > So I found several things that differ between Wine & Windows. Many thanks for reporting this bugs! Please continue reporting anything you find that might prevent your apps to work correctly under Wine. > ############################# > 1.) > > If found out that InvalidateRect with a "zero extent rectangle" > returns FALSE with Wine, while it returns TRUE in Windows. > Wine builds from last year did not show this behavior. > > > Windows: > InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns TRUE; > > Wine > InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns FALSE; A fix for this bug has been committed to CVS. > #################### > 2.) > > Then I discovered an incompatibility with LB_SELITEMRANGE: > > > SendMessage(hWndControl,LB_SELITEMRANGE,TRUE, > MAKELPARAM(wFirst, wLast)); > > Windows accepts values for wLast that are greater than the > list size and performs the operation with the (internally corrected) > value - returning TRUE. > > Wine does not accept a value for wLast if it is greater than > the list size and returns FALSE (not performing the select operation, > which caused subsequent failures in our application). I just sent a patch to wine-patches which should fix this bug. > #################### > 3.) > There is also a different behavior of SetCapture(hWnd) in Wine. > If an overlapped window has captured the mouse input and a new > child window is being openend, Windows internally releases the > capture. Wine maintains the capture - dialogs in our application > may not be operated with the mouse, because the parent still gets > all the mouse messages. Could you please send a small test app demonstrating this behaviour? -- Dmitry.

Dec. 1, 2005