wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: Support Ordinal forwarding in Dll loading
by Alexandre Julliard 29 Jun '01

29 Jun '01

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > In attempting to use Specmaker to create a forwarding DLL to do testing of > the Rebar and ComboBoxEx controls, I ran into a problem where pe_image.c did > not support forwarding an ordinal only reference. This patch allows that > function to work. The ordinal forward is of the form: > dllname.DLLNAME_nnnn. I don't think Windows supports something like this. I would suggest instead to fix specmaker to not generate a forward in this case. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Proper detection of VM86 support
by Alexandre Julliard 28 Jun '01

28 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Proper detection of VM86 support > on FreeBSD, Linux and Solaris added. I don't think that's useful. Even if we someday support vm86 on other platforms, this is one of these cases where a simple platform check (#ifdef linux) is preferable to complex configure magic IMO. This is how we do the LDT check too, because there simply isn't enough similarity between platforms to justify configure tests. -- Alexandre Julliard julliard(a)winehq.com

1 0

[Problem report] Messages cooked too much ?
by Gerard Patel 27 Jun '01

27 Jun '01

This is a problem of intermittents hangings, when moving the mouse or closing a window (not obvious). I finally realized that the traces in the hanging of Eudora 4 looked very similar, but Eudora 4 hangs reliably ;-) I have found this Eudora crash an infinite loop generated by a mouse move message, cooked to generate a WM_NCMOUSEMOVE, then this last message is obtained repeatedly from the server without being ever removed. It does not seem right to peek a cooked message off the server, not find anything useful to do with it, and just ignore it and asking the server again. The following patch removes the problem, and *seems* to cure the intermittent hangings of other apps. Gerard --- message.c.orig Wed Jun 27 22:14:07 2001 +++ message.c Wed Jun 27 22:13:57 2001 @@ -790,7 +790,11 @@ if (qmsg.kind == RAW_HW_MESSAGE || qmsg.kind == COOKED_HW_MESSAGE) { if (!process_hardware_message( &qmsg, hwnd, first, last, flags & PM_REMOVE )) + { + if (qmsg.kind == COOKED_HW_MESSAGE) + if (!(flags & PM_REMOVE)) QUEUE_FindMsg( hwnd, first, last, TRUE, &qmsg ); goto retry; + } } else {

1 0

Re: docu patch
by Alexandre Julliard 26 Jun '01

26 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > diff -u -r1.9 DEVELOPERS-HINTS > --- DEVELOPERS-HINTS 2001/01/10 23:59:25 1.9 > +++ DEVELOPERS-HINTS 2001/06/26 23:02:00 > @@ -23,6 +23,7 @@ > > GDI: > > + console/ - handling of text consoles > graphics/ - graphics drivers > x11drv/ - X11 display driver > win16drv/ -> see below > @@ -58,7 +59,7 @@ > msnet/ > msvcrt/ - C runtime library > msvideo/ - 16 bit video manager > - ole32/ - 32 bit OLE 2.0 librairies > + ole32/ - 32 bit OLE 2.0 libraries > oleaut32/ - 32 bit OLE 2.0 automation > olecli/ - 16 bit OLE client > oledlg/ - OLE 2.0 user interface support > @@ -86,12 +87,13 @@ > > Miscellaneous: > > - misc/ - shell, registry, winsock, etc. > + misc/ - misc. wine management, registry, etc. > ipc/ - SysV IPC based interprocess communication > - win32/ - misc Win32 functions > ole/ - OLE code > - nls/ - National Language Support > + nls/ - National Language Support > configuration files > + unicode/ - Unicode (character) support > + win32/ - misc Win32 functions > I have nothing against updating the doc, but I don't think adding wrong information is going to help <g>. console/ is not a GDI directory, and there is no top level nls/ directory. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: configure.in patch
by Marcus Meissner 26 Jun '01

26 Jun '01

On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > * configure.in: > Remove a redundant check for flex. It is not redundant! AC_PROG_LEX does more than just look for the 'lex' binary. Please do not apply. Ciao, Marcus > -AC_PROG_LEX > AC_CHECK_PROGS(XLEX,$LEX flex lex,none) > if test "$XLEX" = "none" > then

3 5

change of style in the edit control
by Bill Medland 26 Jun '01

26 Jun '01

Is anyone working on the edit control's handling of WM_STYLE_CHANGED? Does anyone have any useful information? I intend adding handling of WM_STYLE_CHANGING/ED to controls/edit.c for our application (which uses SetWindowLong to modify the style after creation). 1. Does anyone know why the EDITSTATE.style is not fed back to the pWnd->dwStyle after being modified. 2. Does anyone know of any documentation of the interaction within windows when the styles are incompatible? Bill

1 0

Apps DB round 2
by Jeremy Newman 26 Jun '01

26 Jun '01

The new Application DB (http://wine.codeweavers.com/appdb/) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments, and flames [:-)] as possible this week. We need volunteers to take responsibility for updating Apps in the DB. If you would like to help, email the appDB team at appdb(a)codeweavers.com. Areas we need help on: - Add Apps and App Versions. - Comments on Apps - Application Owners (the app db has a privilege system where you can be owner of an app.) - Screenshots (lots of 'em) --- _ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com | .` / -_) V V / ' \/ _` | ' \ -= mailto:jnewman@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

9 12

undefined reference to main in _start
by Gilroy Billard 25 Jun '01

25 Jun '01

Hi, I can't link in any version of the WINE libraries after version 20001202 without getting a linker error: undefined reference to main in function _start. I compile WINE with these options: ./configure --without-x --without-curses --disable-debug --disable-trace. Any ideas??? thanks, Gilroy Billard mailto:gilroy@trakonic.com Software Developer Trakonic Inc. PH: 1-902-450-0922 FX: 1-902-450-0939 1-877-419-3887 http://www.trakonic.com

5 6

Re: Win16 calls by Win32 functions
by Alexandre Julliard 25 Jun '01

25 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Sure Win32 calls to Win16 should be eliminated that is > without question. This is how Windows NT does it and > Alexandre has a policy that Wine should doing like > Windows NT does. I fully agree. > > However I'm not positive that replacing Win16 calls to > Win16 with Win32 calls is always good idea. See below. As a rule it is a good idea, but there are of course exceptions. Basically the rule should be that wherever you can choose between a Win16 or Win32 function to do something, you should pick the Win32 function. But in the cases where the Win16 and Win32 functions have different semantics, then of course you have to use the correct one, even if in some cases it means calling Win16 functions from Win32 (like for the GlobalAlloc stuff). -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Win16 calls by Win32 functions
by Patrik Stridvall 25 Jun '01

25 Jun '01

> "Patrik Stridvall" <ps(a)leissner.se> wrote: > > > Noticing that you (Dimitry) have send in a few patch > > replacing Win16 calls by Win32 ones, I wish to > > point out that winapi_check can detect "illegal" > > calls from Win32 to Win16. > > > > Just do > > winapi_check --cross-call-win32-win16 > > Great! Why didn't you just make a patch and submit it? Well. Because I don't want to blindly do search and replace I haven't got around to do it since it will take some time to analyze each case for correctness. It is on my list of things to do but it has very low priority. But since you seems to be doing it, I might just as well tell you how to easily find many of them. > > Note that some of the fixes in your (Dimitry's) > > patches is not included in the result below > > because they are Win16 functions calling Win16 > > functions. > > > > I do not say this is nessary wrong, but are > > you (Dimitry) really sure this is how it should be? > > Well, as Alexandre already has pointed out, Win16 should be > mostly implemented by using Win32. I agree with him that use > of the 16-bit code should be eliminated as much as possible. > Moreover, until now I just have replaced only obvious places: > 16-bit functions which just thunk up to win32 without any > argument processing. Sure Win32 calls to Win16 should be eliminated that is without question. This is how Windows NT does it and Alexandre has a policy that Wine should doing like Windows NT does. I fully agree. However I'm not positive that replacing Win16 calls to Win16 with Win32 calls is always good idea. See below. > > Sure it probably runs a little faster, but then Win16 > > applications on a modern computer are likely to be > > _very_ fast, so it is really worth risking potential > > compabillity errors because of some probably irrelavant > > speed differences. > > > > Not that functions like DeleteObject are likely to > > have such problems but still... > > I'm not going to blindly replace 16-bit calls by 32-bit. > I look into the code and do think twice before submitting > a patch. Of course you are not, but there might be subtle issues that break the code in the future then the full Win32 semantics is implemented. That requires much more thinking than just casually browsing the code and reading the documentation. Actually just thinking and reading documentation is not enough either Win32 or Win16 might have undocumentation features on Windows not implement by Wine yet. Note that I'm not convinced is a large problem if any at all. I'm just worried and think we need to think this through carefully. So what should we do? Correct me if I'm wrong but because of the DLL separation Win16 to Win16 calls between different DLL:s (or rather different .so files) must not take place. I notice that, for example, user32.spec contains the following lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallNextHookEx16(long long long long) CallNextHookEx16 @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall SetWindowsHookEx16(long long long long) SetWindowsHookEx16 @ stdcall UserYield16() UserYield16 and gdi32.spec contains these lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CreateMetaFile16(str) CreateMetaFile16 @ stdcall CloseMetaFile16(long) CloseMetaFile16 This is what is guess Alexandre wants eliminated not calls like the call in SetDCState16 (Win16 GDI) to DeleteObject16 (Win16 GDI) that you "fixed" in one of your patches. Of course Win32 to Win16 calls should be fixed even within a DLL but that is because of possible different semantics not because of the DLL separation. In short I suggest the following policy 1. No Win32 to Win16 calls: This is because of semantic and speed reasons. 2. No Win16 to Win16 calls between different DLL:s: This is because of the DLL separation. 3. No Win16 to Win32 calls within a DLL (with the exception a function's Win32 counterpart or replacement in the case of obsolete function): This is because of semantic reasons but I'm not sure how hard we must enforce point, because if the the Win32 function generates a non Win16 message or some other non Win16 related stuff I guess we can quite easily can (and perhaps even now does) ignore or filter such things in more fundamental part of the code like in the message dispatching code.

1 0

Jump to page:

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