wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Port to Sparc64
by Jutta Wrage 21 Mar '01

21 Mar '01

Hi! What about the suggested port to Sparc? Did anybody work on that again? There was a question in the Wine-HOWTO mailing list. cu Jutta -- http://www.witch.westfalen.de/ Wine-HOWTO http://www.la-sorciere.de/wine/

2 1

any questions?
by Natanael Copa 21 Mar '01

21 Mar '01

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

1 0

Port to OS/390 mainframe USS?
by James.Robinson＠crowley.com 21 Mar '01

21 Mar '01

Will there be a port of WINE to OS/390 mainframe USS? LINUX runs fine under USS, so it would seem that WINE should run there as well. Has anyone done this yet? Thanks James Robinson james.robinson(a)crowley.com

4 3

any questions?
by Natanael Copa 21 Mar '01

21 Mar '01

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Does the attached patch look as applicable? Yep, looks good. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: x11drv patch
by lawson_whitney＠juno.com 20 Mar '01

20 Mar '01

On Mon, 19 Mar 2001, Ove Kaaven wrote: > Here's some more x11drv code... in addition to the HAL bits, it adds some > gamma control stuff, so we can implement Get/SetDeviceGammaRamp (in GDI). > > Log: > Ove Kaaven <ovek(a)transgaming.com> > Added gamma ramp code to the XVidMode interface. Good day! I think this misses x11ddraw.h. At least, I don't have it. xvidmode.c:16: x11ddraw.h: No such file or directory I will find it though. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

2 2

wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed
by Dmitry Timoshkov 20 Mar '01

20 Mar '01

Hello all. I have this very strange situation: Debugging with +relay,+win,+region,+message has revealed: ... Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] WM_GETDLGCODE sent from self wp=00000000 lp=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] WM_GETDLGCODE returned 00000100 wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - info->output)' failed. err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) fs=0287 It seemed to be as libc bug and I have upgraded my stock rh 6.2 from ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. Any suggestions?

2 1

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set. I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. It's unlikely we are ever going to support proper LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of > undesirable LOAD_LIBRARY_AS_DATAFILE? Not necessarily, it may be considered a feature to load version info from the native dll, even though the actual code will run from the builtin. This may help programs believe they got the exact version they wanted (since presumably the app installed the dll in the first place). > Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future? Unlikely; the problem is that we cannot prevent constructors from running, and we need to resolve imports before running constructors. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > But here is a problem. This doesn't honor a load order. If load order > of a requested dll explicitly specified as 'builin' but 'native' library > there is somewhere in the path, then we will get unexpected result. > How to cope with it? I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. -- Alexandre Julliard julliard(a)winehq.com

2 1

fixme:win32:DeviceIoControl Unimplemented control 104 for VxD device SECPROV
by Achilleas Mantzios 19 Mar '01

19 Mar '01

Does anyone have a clue??? P.S. You have done serious job :) i wanna say. -- Á÷éëëÝáò ÌÜíôæéïò Application Developer Eurisko A.E. ÐéíäÜñïõ 9 106 71 ÁèÞíá Ôçë: +301 3633362 Öáî: +301 3633074 e-mail: achilleas.mantzios(a)eurisko.gr

1 0

Re: RFC: client side implementation of async I/O
by Mike McCormack 19 Mar '01

19 Mar '01

Hi All, WWW reported that my client side async patch relies on the service thread... sorry for not clearly explaining, but it doesn't. It works by multiplexing the server's wait reponse fd with pending i/o operation fds using poll. When i have time, i'll try to clean it up a bit. Currently i'm working on a kernel patch to help implement other WaitCommEvent flags. i hope Alexandre considers applying the client side async patch in some form. Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 11:44 PM 17/03/2001 -0500, you wrote: >Strange but true. I reverted the patch, and alt-b beeps but does not >cause a crash. With the patch in, wine crashes without a beep. > >Now I guess I'll put it back in. It doesn't cripple me if wine crashes >when I fat-finger the GUI. I guess wine-devel doesn't want to see a >trace, and maybe you don't either, but if you do it will save time to >send it. I had left out some cases in my first try :/, but maybe it's better to understand firsst what the app is doing. Could you send me a complete (from start) +relay,+menu trace of your app crashing with current Wine (no copy to wine-devel is best in this case) If you can apply the following patch to enhance trace first : --- menu.c.orig Sun Mar 18 10:18:31 2001 +++ menu.c Sun Mar 18 11:28:29 2001 @@ -1852,6 +1852,7 @@ LPWSTR prevText = IS_STRING_ITEM(item->fType) ? item->text : NULL; debug_print_menuitem("MENU_SetItemData from: ", item, ""); + TRACE("flags=%x str=%p\n", flags, str); if (IS_STRING_ITEM(flags)) { @@ -4511,6 +4512,9 @@ { if (!menu) return FALSE; + debug_print_menuitem("MENU_SetItemInfo_common from: ", menu, ""); + TRACE("mask=%x type=%x text=%p\n", lpmii->fMask, lpmii->fType, lpmii->dwTypeData); + if (lpmii->fMask & MIIM_TYPE ) { /* Get rid of old string. */ if ( IS_STRING_ITEM(menu->fType) && menu->text) { @@ -4589,7 +4603,7 @@ if (lpmii->fMask & MIIM_DATA) menu->dwItemData = lpmii->dwItemData; - debug_print_menuitem("SetMenuItemInfo_common: ", menu, ""); + debug_print_menuitem("SetMenuItemInfo_common to : ", menu, ""); return TRUE; } Thanks. Gerard

2 1

Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 10:26 PM 16/03/2001 -0500, you wrote: > >On a related note, I provoked that crash in menu.c again, this time by >hitting an accelerator key (?) for a button that was not enabled at the >time. First thanks for the bug report. The trace is not difficult to read, the menu item is a text item and the text pointer is NULL. MENU_CalcItemSize is not handling this case. What is strange is this problem appears only with my patch. Maybe your app is really initializing the menu when receiving the WM_INITMENU message, but *only* when there is need to display the menu. I can't see how it could find out about it, though. Anyway, could you try the following patch ? It tries to remove the main case I saw where the app can set a menu item to text type with a null text pointer. It is a legitimate patch by itself, even if it does not fix your problem. Maybe it could have nasty side effects. If it avoids the systematic crash, try to find if the other is really gone for good too. I have found a strangeness in the HEAP_strdup macros - WARNING - this is of interest to anyone dabbling with Wine code. While HEAP_strdupW and HEAP_strdupAtoW appear very similar, the specs are not the same; one returns a null pointer when called with a null pointer, the other allocates 2 bytes of memory and returns a pointer to it. Nice trap :-) Gerard --- menu.c.orig Wed Mar 14 20:19:46 2001 +++ menu.c Sat Mar 17 14:47:30 2001 @@ -4524,11 +4524,15 @@ menu->text = lpmii->dwTypeData; - if (IS_STRING_ITEM(menu->fType) && menu->text) { - if (unicode) - menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); - else - menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + if (IS_STRING_ITEM(menu->fType)) { + if (menu->text) { + if (unicode) + menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); + else + menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + } + else + menu->fType |= MF_SEPARATOR; } }

2 2

Re: [PATCH] Version info for comctl32.dll
by gerard patel 18 Mar '01

18 Mar '01

At 10:10 AM 15/03/2001 +0800, you wrote: >I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable >defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls >in ONE place. Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly. Unless the version number of winsock.dll, richedit.dll, version.dll, or unrelated dlls like that is always identical to the version number of common controls ? I did not check but that seems unlikely. >1. I believe that version numbers should be equal in both numerical field and >in the string value (0.01 != 4.72 and 1.00 != 4.72). >2. There is no need for excessive \000 at the end of the string value. >3. All well behaving programs do read "VarFileInfo"/"Translation" before >retrieving other version information. LANGUAGE does nothing here. >4. Did you try to use my sample application showing version info? >5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve >as an example of adding version resources into built-in dlls. Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-) I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource. Gerard

3 23

Re: [PATCH] Version info for comctl32.dll
by gerard patel 17 Mar '01

17 Mar '01

At 08:54 PM 15/03/2001 -0500, you wrote: <snip> >for its version info and gets the builtin. The ver trace looks a little >strange to me - maybe it will make sense to you? Do you mean a strangeness that could go away with the following patch : --- info.c.orig Fri Feb 23 21:37:15 2001 +++ info.c Fri Mar 16 10:14:19 2001 @@ -503,8 +503,15 @@ && !VersionInfoIs16( data ) ) { /* convert resource from PE format to NE format */ - ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, - (VS_VERSION_INFO_STRUCT16 *)data ); + BYTE *ptemp = HeapAlloc(GetProcessHeap(), 0, datasize); + if (ptemp) + { + ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, + (VS_VERSION_INFO_STRUCT16 *)ptemp ); + memcpy(data, ptemp, datasize); + HeapFree(GetProcessHeap(), 0, ptemp); + + } } return TRUE; I don't think this will fix your problem, though. Gerard

2 1

Re: [PATCH] Recalculate menus after WM_INITMENU
by lawson_whitney＠juno.com 17 Mar '01

17 Mar '01

On Mon, 12 Mar 2001, gerard patel wrote: > StatView (www.statview.com) menus don't work at all. > It seems that this app recreates all submenus of the > main menu in the WM_INITMENU handling. > > ChangeLog: > > * controls/menu.c > Recalculate menu sizes if WM_INITMENU has recreated/changed something > > Good day, Gerard! I have noticed a couple of crashes at controls/menu.c 872 since I applied this - when I fatfinger something in the wm (icewm) and keyboard input gets directed to a different window, but the event comes to wine, I think, but I haven't looked into it too closely and I'm not sure I can reproduce it. /* If we get here, then it must be a text item */ if (IS_STRING_ITEM( lpitem->fType )) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); and in this case lpitem is NULL and the strlen crashes. Would you be interested to see traces if I can reproduce it (if so which traces)? I think maybe it is a wm bug, but maybe wine should protect itself if it is not too expensive to do so? Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: Eliminate excessive retries in GetFileVersionInfo(Size)
by lawson_whitney＠juno.com 16 Mar '01

16 Mar '01

Good day! Maybe it takes a Man from Mars to think that a windose function might ought to sort of do what its name implies, but the more I think about it, wouldn't it be simpler? It is right and proper for the functions of oleaut32.dll to be performed by liboleaut32.so and friends (if the Wine administrator so directs), but if the app asks for the version info for oleaut32.dll, and the named file exists (because the app's installer _put_ that file there, in this case) how about we give it the version info from that bloody file? If the file doesn't exist, we give it a builtin construct, say. IOW, disconnect file version from dll. I don't think it is any business of the app what does its work, so I don't see why it should be able to tell by GetFileVersionInfo whether the working blah.dll is builtin or native. I guess you could make a case for a [VersionOverrides] section in the config, but I am not going to. That way lies madness. I would be willing to take a shot at writing the code if that's what we decide we want, and if no one is in a great hurry for it, but... Regards, Lawson << Sardines of the world unite! << >> You have nothing to lose but your cans. >> ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: Eliminate excessive retries in GetFileVersionInfo(Size) (fwd)
by lawson_whitney＠juno.com 15 Mar '01

15 Mar '01

Oops, I misdirected this to wine-patches before. Sorry. On Thu, 15 Mar 2001, Dmitry Timoshkov wrote: > Hello. > > This patch helps eliminate excessive retries in GetFileVersionInfo(Size). > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Return from GetFileVersionInfo(Size) if specified file found, > but VS_VERSION_INFO resource not. > Good day! Here we go again. This breaks my app (juno 2.0.11) with builtin ole32/oleaut32. Native ole32/oleaut32 are so full of deadbeef they sort of stink. I guess we don't need to panic yet. I can revert it locally until so I can get and send mail until I see if I (or someone) can make some builtin version resources that will satisfy this app. It installs its own oleaut32.dll and with this patch in it thinks the install is busted. Regards, Lawson It is better to be lucky than good. - J. A. Soucy ---

1 0

Re: winedefault patch
by Andreas Mohr 15 Mar '01

15 Mar '01

On Wed, Mar 14, 2001 at 09:35:17PM +0100, Ove Kaaven wrote: > Wine won't load builtin dlls if a full path to a nonexistent file is > specified, so the default registry should probably not have a full path to > dplayx.dll. Some guy managed to start Settlers 3 after this was fixed... > > Log: > Removed path from dplayx registry entry, so that the builtin dplayx can be > loaded. Alexandre, please add a comment to winedefault.reg reminding people of this problem for future entries. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard 15 Mar '01

15 Mar '01

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > I am not exactly sure what you mean by this. Do you mean to put the > code that would be in the dll, into the debugger, or to extend the > debugger in such a way that it can load dll's to enhance its > functionality, or something else? I mean that the code that would have been in the dll and loaded into Wine should be in the debugger instead. So for instance, instead of having a magic key (or X message) to switch tracing on, you'd have a debugger command 'set tracing on' that would poke into the Wine address space to do it. Since you can read/write memory, call functions (I think it's broken now but should be easy to fix), etc. from the debugger you can do everything from here and avoid the need to have any debugging code running inside the Wine process. > This would bypass the objection of intercepting a key, like F12, and > using it to generate a window list dump, and replace it with a > mechanism that uses the debugger own builtin functions to do that. Yes, exactly. > I think it is desirable to use as much of the existing debugger > functionality as possible, and to add an "elaborate mechanism in the > debugger" that allows it to be dynamically extended in > functionality. It would certainly be possible to load dlls inside the debugger itself to extend it; though maybe simply loading a batch file containing debugger commands may allow to do a lot of things already without requiring compiling new code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] Version info for comctl32.dll
by Dmitry Timoshkov 15 Mar '01

15 Mar '01

"gerard patel" <gerard.patel(a)asi.fr> wrote: > ChangeLog: > > * dlls/comctl32/rsrc.rc > Add version info. [...] > LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +1 VERSIONINFO > +FILEVERSION 4, 72, 0, 0 > +PRODUCTVERSION 4, 72, 0, 0 > +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > +FILEOS VOS_DOS_WINDOWS16 [...] > + VALUE "FileVersion", "0.01\000" [...] > + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard 14 Mar '01

14 Mar '01

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > My current design is to have yet another dll that would register > itself as the handler for this XClientMessage, so that on reciept of > the XClientMessage, it is simply passed to this new dll. This dll > would implement whatever application specific debugging tools I > need, with only the bare minimum of support from wine needed. Since > the wine debugger already has quite a bit of the functionality that > is needed, it might be interesting if this method could be used to > effectively open a pipe and drive the wine debugger externally. What you should rather do IMO is to put your dll inside the debugger, and have the debugger drive Wine instead of the other way around. Then you can add all kinds of elaborate mechanisms in the debugger, and do anything you want without needing any cooperation from the running Wine process. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: Problems with WM_NCHITTEST and HTTRANSPARENT
by Patrik Stridvall 14 Mar '01

14 Mar '01

> I'm currently having problems with this situation: > > Thread 1 owns some controls (modeless dialog box, actually) > > Thread 2 owns a window that covers the dialog (let's say it's like a > "skin" or something...) > > The window procedure for thread 2's window return HTTRANSPARENT in its > WM_NCHITTEST handler, so in theory mouse messages should get > passed down > to thread 1's controls. Now, what happens is this... [snip] > Any ideas on how to solve this, or whether it's supposed to work at all? I > think I could fix some games if this worked... otherwise I'll have to > think of some other way... >From MSDN: < HTTRANSPARENT < In a window currently covered by another window in the same thread < (the message will be sent to underlying windows in the same thread < until one of them returns a code that is not HTTRANSPARENT). Note "window in the same thread". So it seems that you (Wine) shouldn't pass down mouse messages to thread 1 in your example.

1 0

Problems with WM_NCHITTEST and HTTRANSPARENT
by Ove Kaaven 14 Mar '01

14 Mar '01

I'm currently having problems with this situation: Thread 1 owns some controls (modeless dialog box, actually) Thread 2 owns a window that covers the dialog (let's say it's like a "skin" or something...) The window procedure for thread 2's window return HTTRANSPARENT in its WM_NCHITTEST handler, so in theory mouse messages should get passed down to thread 1's controls. Now, what happens is this... -Mouse message arrives at thread 2 -TranslateMouseMsg calls WINPOS_WindowFromPoint -WINPOS_WindowFromPoint sends a WM_NCHITTEST to window -Window procedure returns HTTRANSPARENT -WINPOS_WindowFromPoint finds the controls, and returns that -TranslateMouseMsg wakes owner of controls (thread 1) -Mouse message arrives at thread 1 -TranslateMouseMsg calls WINPOS_WindowFromPoint -Since the transparent window is not owned by the current thread, WINPOS_WindowFromPoint doesn't bother to send it a message, but rather returns HTCLIENT directly -WINPOS_WindowFromPoint returns the transparent window -TranslateMouseMsg wakes thread 2 Repeat. This blocks all further mouse input processing, by the way... Any ideas on how to solve this, or whether it's supposed to work at all? I think I could fix some games if this worked... otherwise I'll have to think of some other way...

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel