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

[winelib] Can't figure out a Winemaker error

by Scott Ritchie

As part of my effort to create a successful demonstration of how to port something, I tried out winelib. Unfortunately, I can't seem to get it working at all. I get this error whenever I run winemaker: Global symbol "%directories" requires explicit package name at /usr/bin/winemaker line 423. Global symbol "%directories" requires explicit package name at /usr/bin/winemaker line 441. Execution of /usr/bin/winemaker aborted due to compilation errors. What's going on here? Did I screw something up, or was this broken in that release? This is with the December release. Thanks, Scott Ritchie

Dec. 14, 2004

Re: Should we get rid of the wine-license list?

by Dimitrie O. Paun

On Tue, Dec 14, 2004 at 08:35:26PM -0800, Scott Ritchie wrote: > Looking at the archives it appears that wine-license has had very little > traffic, to the point where a lot of it is probably not being read when > it comes up, since people like me are not subscribed to that list. Yeah, I think it we should get rid of it. It was a dead list from the very beginning, and it hasn't seen any significant traffic in a long while. Besides, licensing discussions are rather pointless now, we can't change from LGPL. -- Dimi.

Dec. 14, 2004

Should we get rid of the wine-license list?

by Scott Ritchie

Looking at the archives it appears that wine-license has had very little traffic, to the point where a lot of it is probably not being read when it comes up, since people like me are not subscribed to that list. It seems like a lot of the stuff being sent there should instead go to wine-devel. Thoughts? Scott Ritchie

Dec. 14, 2004

Re: PATCH: revive FreeBSD support

by Gerald Pfeifer

On Tue, 14 Dec 2004, Alexandre Julliard wrote: > Looks OK, but this is a job for wine_anon_mmap, it's supposed to > abstract these sorts of platform dependencies so that the callers > don't have to worry about it. How about the following? Gerald ChangeLog: Make us work on FreeBSD again by working around their different mmap() implementation. Index: README =================================================================== RCS file: /home/wine/wine/README,v retrieving revision 1.47 diff -u -3 -p -r1.47 README --- README 21 Nov 2004 15:33:00 -0000 1.47 +++ README 14 Dec 2004 22:30:53 -0000 @@ -44,10 +44,8 @@ Linux info: it's best to have a current kernel such as 2.4.x. FreeBSD info: - Wine should build on FreeBSD 4.x and FreeBSD 5.x before 5.3, but will - generally not work on these systems due to issues with threading and - mmap(). In fact, even on FreeBSD 5.3 you will need the kernel patch - posted at <http://www.freebsd.org/cgi/query-pr.cgi?pr=73092>. + Wine should build on FreeBSD 4.x and FreeBSD 5.x, but versions before + FreeBSD 5.3 will generally not work properly. More information can be found in the FreeBSD ports tree at <ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/emulators/wine/>. Index: libs/wine/mmap.c =================================================================== RCS file: /home/wine/wine/libs/wine/mmap.c,v retrieving revision 1.8 diff -u -3 -p -r1.8 mmap.c --- libs/wine/mmap.c 4 Nov 2004 04:52:48 -0000 1.8 +++ libs/wine/mmap.c 14 Dec 2004 22:31:08 -0000 @@ -150,6 +150,12 @@ void *wine_anon_mmap( void *start, size_ #ifdef HAVE_MMAP static int fdzero = -1; +#ifdef __FreeBSD__ + /* Even FreeBSD 5.3 does not properly support NULL here. */ + if( start == NULL ) + start=(void *)0x110000; +#endif + #ifdef MAP_ANON flags |= MAP_ANON; #else

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Rémi Assailly

Alexandre Julliard wrote : >The easy stuff has been done already... > Otherwise there would be nothing to do ! I noticed that in gdi.h PC_SYS_MAPPED is unused and PC_SYS_RESERVED is only used in dlls/x11drv/palette.c I think we can remove PC_SYS_MAPPED and move PC_SYS_RESERVED to dlls/x11drv/palette.c In other cases, what do you suggest ? If it is too difficult and if I can only be a cleaner, I'll be a cleaner ;)

Dec. 14, 2004

Re: Includes: x11drv

by Rémi Assailly

Jon Griffiths wrote : >Hi, > >x11drv: 8 includes removed. > >Cheers, >Jon > > +dlls/x11drv/text.c dlls/x11drv/window.c dlls/x11drv/winpos.c > dlls/x11drv/x11ddraw.c > Remove uneeded headers to reduce uneeded rebuilds. > > Hi Jon, As I am working on x11drv I can tell you some things : win.h is declared in x11drv.h so if you want to remove it, remove it from all files. But I think it is not a good idea : win.h is one of the header files which need to be moved so I think it is better to keep #include "win.h" where it is needed. It will be easier to find files which need definitions in win.h. For example you removed win.h from window.c which use the structure WND. I also noticed that you removed wingdi.h from x11ddraw.c. wingdi.h is declared in gdi.h which is a header file which need to be moved too ! So when we get rid of gdi.h we'll must redeclare wingdi.h in x11ddraw.c Regards Rémi

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Alexandre Julliard

Rémi Assailly <remi.assailly(a)free.fr> writes: > Alexandre Julliard wrote : > > >Sure, we can move out definitions that are not needed by other dlls, > >as long as they are for things that won't need to be changed when > >getting rid of the dll dependencies. For DCE and more generally for > >all user32 headers I'd suggest leaving them alone for now, they are > >going to look completely different when I'm done with the wm changes > >anyway. > > > I am not sure to have understood what you told me : you would like me > not to take care of headers like dce.h or cursoricon.h while you are > rewriting wm ? Right, don't touch the user32 headers. Note that other headers will have similar issues; you can certainly start working on them, but you should expect to quickly get into tricky dll separation problems. The easy stuff has been done already... -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Mike Hearn wrote: > > >Perhaps the first step then would be to implement support in winebuild > >and the loader such that the list of stubbed functions is exported then > >the loader can link imports from those to stubs generated on the fly. At > >that point the winebuild support for stubs could be removed, and all the > >@ stub entries also deleted in one go. > > > > I think that's a step backwards. Look, for example, in shlwapi or > shdocvw. There are stubs there that are exported by ordinal only in > the native dll and so removing them would lose the name of the > function. Not to mention that I've fixed one bug with nasty stack > corruption caused by missing ordinal exports. Obviously we can't blindly remove all stubs, each individual case needs to be looked at. But there aren't that many ordinal exports, and adding dummy functions for them shouldn't be that hard. > Also, I see the stubs in the .spec file as a really broad todo list. A > stub in a dll that I am interested in working on tells me to look up > documentation for that function and write a test for it, then > implement it. I don't need an obscure application to let me know that > it is unimplemented. Yes but that doesn't require winebuild support, a commented out entry in the spec file can serve the same purpose. > IMHO, the Wine project should be moving away from just-in-time > implementing of functions and moving towards implementing *everything* > (with some obvious exceptions). This is the only way a high percentage > of applications will work on Wine. Replacing stubs by real functions is a step in that direction IMO. At least this way we'll have prototype information that will make it more likely that someone starts working on the function. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > I would like to point out again that the VC linker will not generate > a correct dll unless the ordinal stubs are present. Other native > linkers may have the same problem. It seems very silly to me that we > can't use M$'s own compiler/linker to build valid dlls (especially > since these tools can be downloaded for free these days). M$ defined > the dll format we are using, after all. Yes, that's exactly why we need to get rid of stubs; there is no such concept on Windows. The solution is not to start building a .spec.c file for MSVC, it's to fix our spec files so that they can work on Windows without generating extra code. This means replacing the stubs by real functions. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: [AppDB] Remove borders=0 from img

by tony_lambregts＠telusplanet.net

Paul van Schayck wrote: > Ok, since we have img{border: 0;} in our stylesheet we can now remove > border=0 from all img elements. > > Changelog: > Remove border=0 from img tags > > A patch would be nice.. ;-) -- Tony Lambregts

Dec. 14, 2004

Re: "Debugging" a password dialog

by David Gümbel

On Montag 13 Dezember 2004 18:03, you (Andreas Mohr) wrote: > On Sun, Dec 12, 2004 at 01:21:44AM -0800, Walt Ogburn wrote: > > Sorry, I was thinking of the debug channels, but I don't know which > > ones to use, short of turning on "trace+all." > > Probably something like +edit,+relay,+string Thanks, I'll try that ;) Bye, David

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Rémi Assailly

Alexandre Julliard wrote : >Sure, we can move out definitions that are not needed by other dlls, >as long as they are for things that won't need to be changed when >getting rid of the dll dependencies. For DCE and more generally for >all user32 headers I'd suggest leaving them alone for now, they are >going to look completely different when I'm done with the wm changes >anyway. > I am not sure to have understood what you told me : you would like me not to take care of headers like dce.h or cursoricon.h while you are rewriting wm ? If you wanted to say that, I will work on others headers. Rémi

Dec. 14, 2004

Re: Stubs in PE build

by Mike Hearn

On Tue, 2004-12-14 at 12:01 -0500, Dimitrie O. Paun wrote: > On Tue, Dec 14, 2004 at 10:16:29AM -0600, Robert Shearman wrote: > > IMHO, the Wine project should be moving away from just-in-time > > implementing of functions and moving towards implementing *everything* > > (with some obvious exceptions). This is the only way a high percentage > > of applications will work on Wine. > > I second that, especially for the visible (UI elements). Otherwise we > will always have ugly artifacts that make apps run under wine look rather > unprofessional/unpleasant. At best, the user doesn't get a worm and fuzzy > feeling. In reality, we're losing (quite a bit of) mindshare. UI polish is definitely important, but I think just-in-time development is our only choice right now. If keen hackers were lining up at the door desperate to write patches then yeah, maybe we could rethink, but as it is new people who just write general patches (ie, aren't just interested in one specific app or DLL) join the project fairly rarely. Telling people to just implement random functions that may be called by one in ten thousand apps doesn't make any sense. The widget library is one exception to that I think: the rebar control is horribly busted right now but not quite busted enough to actually crash popular apps, with the result that nobody works on it. So improving the code for its own sake makes sense there. thanks -mike

Dec. 14, 2004

Re: wineprefixcreate and config file

by James Hawkins

On Tue, 14 Dec 2004 09:04:17 -0200, Raul Dias <raul(a)dias.com.br> wrote: > Hi, > > Shouldn't tools/wineprefixcreate copy a sample config file? > > Right now it does all the job to create a standalone wine environment, > but with no config. > > I would suggest copying documentation/samples/config to tools/config, > installing it at $(SRCDIR) and them just copying it during > wineprefixcreate call. > > I can do that if no one disagrees with the change. > > Some rpms in the sourceforge does not even have the sample config file > in it. > > -- > Raul Dias > > We're in the process of removing the config file. As of a couple release ago (not sure how many) you can run wine without a config file, because the settings are being moved into the registry, and someday will be easily changed with winecfg. -- James Hawkins

Dec. 14, 2004

Re: Stubs in PE build

by Steven Edwards

Hi Jon, --- Jon Griffiths <jon_p_griffiths(a)yahoo.com> wrote: > I would like to point out again that the VC linker will not generate > a correct dll unless the ordinal stubs are present. Other native > linkers may have the same problem. It seems very silly to me that we > can't use M$'s own compiler/linker to build valid dlls (especially > since these tools can be downloaded for free these days). M$ defined > the dll format we are using, after all. Is there anyway we could add some magic to msvcmaker to do this? It seems to me that if we need to have the stubs defined in a source file on msvc we can have msvcmaker parse the spec files and generate a extra source file when its making the makefiles. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

Dec. 14, 2004

Re: Stubs in PE build

by Dimitrie O. Paun

On Tue, Dec 14, 2004 at 10:16:29AM -0600, Robert Shearman wrote: > IMHO, the Wine project should be moving away from just-in-time > implementing of functions and moving towards implementing *everything* > (with some obvious exceptions). This is the only way a high percentage > of applications will work on Wine. I second that, especially for the visible (UI elements). Otherwise we will always have ugly artifacts that make apps run under wine look rather unprofessional/unpleasant. At best, the user doesn't get a worm and fuzzy feeling. In reality, we're losing (quite a bit of) mindshare. -- Dimi.

Dec. 14, 2004

Re: Stubs in PE build

by Robert Shearman

Mike Hearn wrote: >On Tue, 2004-12-14 at 15:41 +0100, Alexandre Julliard wrote: > > >>Not adding the functions at all is even easier, and the results are >>pretty much the same... As you noted, in general the only advantage of >>stubs is that you get a better error message, but that would be fairly >>easy to handle at the loader level. The problem with adding stubs >>everywhere is that now we don't know which ones are really needed. >> >> > >Hmm, you mean we could remove the spec file entries that apps never >actually link against? > > I would like to remove the Callback* stubs in kernel32, that aren't linked to by any apps and aren't present in the WinNT kernel32. >Perhaps the first step then would be to implement support in winebuild >and the loader such that the list of stubbed functions is exported then >the loader can link imports from those to stubs generated on the fly. At >that point the winebuild support for stubs could be removed, and all the >@ stub entries also deleted in one go. > > I think that's a step backwards. Look, for example, in shlwapi or shdocvw. There are stubs there that are exported by ordinal only in the native dll and so removing them would lose the name of the function. Not to mention that I've fixed one bug with nasty stack corruption caused by missing ordinal exports. Also, I see the stubs in the .spec file as a really broad todo list. A stub in a dll that I am interested in working on tells me to look up documentation for that function and write a test for it, then implement it. I don't need an obscure application to let me know that it is unimplemented. IMHO, the Wine project should be moving away from just-in-time implementing of functions and moving towards implementing *everything* (with some obvious exceptions). This is the only way a high percentage of applications will work on Wine. Rob

Dec. 14, 2004

Dodgy NetBSD code in dlls/kernel/cpu.c?

by Jon Griffiths

Hi, in dlls/kernel/cpu.c, around line 430, is the following code for NetBSD: { int mib[2]; int value[2]; ... if (sysctl(mib, 2, value, value+1, NULL, 0) >= 0) if (value) PF[PF_FLOATING_POINT_EMULATED] = FALSE; else PF[PF_FLOATING_POINT_EMULATED] = TRUE; This looks dodgy, the "if (value)" test will always be true. I gather it should be "if (value[0])" or "if (value)[1]", but I'm no NetBSD guru. Also, there should be not need to set values to FALSE, since the flag array is cleared to 0 at the start of this function. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 14, 2004

Re: Visual studio 6 build fix.

by Rein Klazes

On Sun, 12 Dec 2004 14:02:54 +0100, you wrote: > > Is this one acceptable? > > > > If there is still a problem, then I need more hints to what is needed. > the only part which is questionnable is as follows: > - what happens (in your case) if the child (after being run through all the > init) calls FreeConsole and then AllocConsole? > - I don't know the answer. The patch will let the new standard handles be still > the ones the child as inherited, while it could be the ones allocated by > AllocConsole. > I don't know the answer for sure (my wild guess would be the second), but that > requires testing (and a proper test case for winetest wouldn't hurt of course). > If I'm right, then you should keep AllocConsole as it is and in > dlls/kernel/kernel_main.c set the default handles to what's inherited after > calling AllocConsole Eric, Testing on Win2K: If I do a FreeConsole() & AllocConsole() in a child that has obtained stdio handles from the StartupInfo struct, I get exactly the same handles. Even the CREATE_NEW_CONSOLE flag is irrelevant. In contrast, if the handles are just inherited (no STARTF_USESTDHANDLES flag), I get new handles directed to the new console. So, with luck, I think my approach seems the correct one. Resubmitting, with minor cleanups. Changelog: server : process.c dlls/kernel : console.c A starting process must obey the STARTF_USESTDHANDLES flag and use the standard io handles from the StartupInfo structure, even it is starting a new console. Rein.

Dec. 14, 2004

Re: Stubs in PE build

by Mike Hearn

On Tue, 2004-12-14 at 15:41 +0100, Alexandre Julliard wrote: > Not adding the functions at all is even easier, and the results are > pretty much the same... As you noted, in general the only advantage of > stubs is that you get a better error message, but that would be fairly > easy to handle at the loader level. The problem with adding stubs > everywhere is that now we don't know which ones are really needed. Hmm, you mean we could remove the spec file entries that apps never actually link against? Perhaps the first step then would be to implement support in winebuild and the loader such that the list of stubbed functions is exported then the loader can link imports from those to stubs generated on the fly. At that point the winebuild support for stubs could be removed, and all the @ stub entries also deleted in one go. thanks -mike

Dec. 14, 2004

Re: Stubs in PE build

by Jon Griffiths

Hi, I had a patch which enabled stub generation for building native dlls last year (http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html) that part was not accepted for the same reasons that are being mentioned in this thread. I would like to point out again that the VC linker will not generate a correct dll unless the ordinal stubs are present. Other native linkers may have the same problem. It seems very silly to me that we can't use M$'s own compiler/linker to build valid dlls (especially since these tools can be downloaded for free these days). M$ defined the dll format we are using, after all. If this is intentional, perhaps we should document it somewhere? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > They also make adding new DLLs easier, as you don't have to submit lots of > stub functions for every entry point. I guess we could have a script to > generate them given a header, but still ... Not adding the functions at all is even easier, and the results are pretty much the same... As you noted, in general the only advantage of stubs is that you get a better error message, but that would be fairly easy to handle at the loader level. The problem with adding stubs everywhere is that now we don't know which ones are really needed. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Stubs in PE build

by Mike Hearn

On Tue, 14 Dec 2004 15:13:51 +0100, Alexandre Julliard wrote: > So now it will be a bit of work before we can get rid of > them, but that should be the long term goal; and that's why I don't > think we should add more code to support them. I'm a bit confused, the specfile level stubs are handy if only because when an app calls them you can see exactly which function was called in the error. Otherwise you'd just get a crash at 0xdeadbeef (what if that address is mapped? can that even happen?). It also suppresses all the warnings from the linker when using native DLLs that are linked against internal functions but never use them, for whatever reason. They also make adding new DLLs easier, as you don't have to submit lots of stub functions for every entry point. I guess we could have a script to generate them given a header, but still ... thanks -mike

Dec. 14, 2004

Re: Hang in usr1_handler (ptrace issue?)

by Mike Hearn

On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn wrote: > Lately I've been seeing hangs of this form: > > Backtrace: > =>1 0x4df8e7a2 (0x659ffb54) > 2 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x0, handles=0x0, flags=0x8, timeout=0x659ffd10) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x659ffcf8) > 3 0x5246da88 usr1_handler+0x38(__signal=0xa, __context=0x33) [/source/wine/dlls/ntdll/signal_i386.c:1159] in ntdll (0x659ffd1c) > 4 0x100238a8 (0x65bfc6cc) > 5 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x1, handles=0x65bfc8bc, flags=0x4, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x65bfc870) > 6 0x5246f5df NtWaitForMultipleObjects+0x4b(count=0x1, handles=0x65bfc8bc, wait_all=0x0, alertable=0x0, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:713] in ntdll (0x65bfc898) > 7 0x1894e4b3 WaitForMultipleObjectsEx+0xa3(count=0x1, handles=0x65bfc9f0, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/source/wine/dlls/kernel/sync.c:180] in kernel32 (0x65bfc9c8) > > in other words, whilst waiting on some server object it was suspended. Never mind, I'm an idiot. Winedbg does a SuspendThread on the target before getting a backtrace and so you see the signal stack as a part of the backtrace even though it's not a part of the "real" thread stack. A bit confusing but no big deal. Maybe dbghelp should suppress these frames. thanks -mike

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

"Ge van Geldorp" <gvg(a)reactos.com> writes: > I was mixing native shell32.dll with Wine-derived shlwapi.dll. Native > shell32.dll imports those stubs from shlwapi.dll but then doesn't call them > in our usage scenarios. > I'm just a little bit surprised that stubs are ok for elf builds but not for > PE builds. It's not a big issue, I'm going to keep the code in ReactOS CVS > anyway <g>. Well, they really aren't OK for ELF builds either; the problem is we have added stubs as placeholders all over the place, while we should have only added them where there is a real need (mostly for ordinal imports). So now it will be a bit of work before we can get rid of them, but that should be the long term goal; and that's why I don't think we should add more code to support them. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Alexandre Julliard

Rémi Assailly <remi.assailly(a)free.fr> writes: > Do you agree if I first move all definitions used by only one dll ? ( > in the case of dce.h, we'll just keep > extern BOOL DCE_InvalidateDCE( HWND, const RECT* ) ) > What will stay is inter-dll dependencies and we'll be sure the problem > is here and we'll work on it. Sure, we can move out definitions that are not needed by other dlls, as long as they are for things that won't need to be changed when getting rid of the dll dependencies. For DCE and more generally for all user32 headers I'd suggest leaving them alone for now, they are going to look completely different when I'm done with the wm changes anyway. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Stubs in PE build

by Dmitry Timoshkov

"Ge van Geldorp" <gvg(a)reactos.com> wrote: > > I don't think we want to add a special mode just for stubs; > > they should really be replaced by proper functions (even if > > the functions are stubs themselves, at least they can print > > the parameters and try to return something meaningful instead > > of killing the app). You can view the lack of stubs support > > on PE as an encouragement to help us remove them from the > > spec files ;-) > > Seems impossible for functions with unknown calling conventions and number > of parameters. In that case you can remove those (only a few) stubs from the .spec files, but most of the stubs are well documented APIs. -- Dmitry.

Dec. 14, 2004

RE: Stubs in PE build

by Ge van Geldorp

> From: Alexandre Julliard > > > Seems impossible for functions with unknown calling conventions and > > number of parameters. > > I don't think that's a common case, most of these have been > identified by now. But anyway, if you have an app calling the > function you should be able to determine the number of > parameters; and if you don't then you shouldn't need the stub > at all. Do you have a specific case where this is a problem? I was mixing native shell32.dll with Wine-derived shlwapi.dll. Native shell32.dll imports those stubs from shlwapi.dll but then doesn't call them in our usage scenarios. I'm just a little bit surprised that stubs are ok for elf builds but not for PE builds. It's not a big issue, I'm going to keep the code in ReactOS CVS anyway <g>. Ge van Geldorp.

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Rémi Assailly

Alexandre Julliard wrote : >Rémi Assailly <remi.assailly(a)free.fr> writes: > > > >>Changelog: >>* get rid of dce.h >>--- dlls/x11drv/winpos.c 2004-12-09 19:10:35.000000000 +0100 >>+++ dlls/x11drv/winpos.c 2004-12-11 19:46:03.000000000 +0100 >>@@ -40,7 +40,6 @@ >> #include "x11drv.h" >> #include "win.h" >> #include "winpos.h" >>-#include "dce.h" >> #include "cursoricon.h" >> #include "nonclient.h" >> >>@@ -49,6 +48,8 @@ >> >> WINE_DEFAULT_DEBUG_CHANNEL(x11drv); >> >>+extern BOOL DCE_InvalidateDCE( HWND, const RECT* ); >> >> > >The goal of the header files cleanup is not to mechanically remove the >#includes by duplicating the definitions, if we wanted to do that it >would have been done long ago. The real goal is to get rid of the >inter-dll dependencies, the global headers are really just a symptom >of the problem. > > Well, I see. Do you agree if I first move all definitions used by only one dll ? ( in the case of dce.h, we'll just keep extern BOOL DCE_InvalidateDCE( HWND, const RECT* ) ) What will stay is inter-dll dependencies and we'll be sure the problem is here and we'll work on it.

Dec. 14, 2004

Re: Stubs in PE build

by Andreas Mohr

Hi, On Tue, Dec 14, 2004 at 11:47:11AM +0100, Ge van Geldorp wrote: > > From: julliard(a)winehq.org > > > > I don't think we want to add a special mode just for stubs; > > they should really be replaced by proper functions (even if > > the functions are stubs themselves, at least they can print > > the parameters and try to return something meaningful instead > > of killing the app). You can view the lack of stubs support > > on PE as an encouragement to help us remove them from the > > spec files ;-) > > Seems impossible for functions with unknown calling conventions and number > of parameters. What's the problem here? If you have an app exercising that function, then you have an object ready for examination already, and if you don't have any app using it, then you don't have any problem anyway... OK, mere mortal endusers might have problems with some apps crashing, but they're easily lost in slightly more severe cases anyway ;) Andreas Mohr

Dec. 14, 2004

wineprefixcreate and config file

by Raul Dias

Hi, Shouldn't tools/wineprefixcreate copy a sample config file? Right now it does all the job to create a standalone wine environment, but with no config. I would suggest copying documentation/samples/config to tools/config, installing it at $(SRCDIR) and them just copying it during wineprefixcreate call. I can do that if no one disagrees with the change. Some rpms in the sourceforge does not even have the sample config file in it. -- Raul Dias

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

"Ge van Geldorp" <gvg(a)reactos.com> writes: > Seems impossible for functions with unknown calling conventions and number > of parameters. I don't think that's a common case, most of these have been identified by now. But anyway, if you have an app calling the function you should be able to determine the number of parameters; and if you don't then you shouldn't need the stub at all. Do you have a specific case where this is a problem? -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

RE: Stubs in PE build

by Ge van Geldorp

> From: julliard(a)winehq.org > > I don't think we want to add a special mode just for stubs; > they should really be replaced by proper functions (even if > the functions are stubs themselves, at least they can print > the parameters and try to return something meaningful instead > of killing the app). You can view the lack of stubs support > on PE as an encouragement to help us remove them from the > spec files ;-) Seems impossible for functions with unknown calling conventions and number of parameters. Ge van Geldorp.

Dec. 14, 2004

Re: PATCH: revive FreeBSD support

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > --- dlls/ntdll/virtual.c 11 Oct 2004 20:59:06 -0000 1.41 > +++ dlls/ntdll/virtual.c 3 Dec 2004 04:06:42 -0000 > @@ -119,6 +119,12 @@ static CRITICAL_SECTION csVirtual = { &c > /* Note: these are Windows limits, you cannot change them. */ > # define ADDRESS_SPACE_LIMIT ((void *)0xc0000000) /* top of the total available address space */ > # define USER_SPACE_LIMIT ((void *)0x80000000) /* top of the user address space */ > +# ifdef __FreeBSD__ > +# define LOW_SPACE_LIMIT ((void *)0x110000) /* lower address space limit */ > +# else > +# define LOW_SPACE_LIMIT NULL > +# endif > + > #else > static UINT page_shift; > static UINT page_mask; > @@ -600,7 +606,7 @@ static NTSTATUS map_view( struct file_vi > > for (;;) > { > - if ((ptr = wine_anon_mmap( NULL, view_size, VIRTUAL_GetUnixProt(vprot), 0 )) == (void *)-1) > + if ((ptr = wine_anon_mmap( LOW_SPACE_LIMIT, view_size, VIRTUAL_GetUnixProt(vprot), 0 )) == (void *)-1) Looks OK, but this is a job for wine_anon_mmap, it's supposed to abstract these sorts of platform dependencies so that the callers don't have to worry about it. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Stubs in PE build

by Alexandre Julliard

Ge van Geldorp <gvg(a)reactos.com> writes: > Send for review to wine-devel: http://www.winehq.org/hypermail/wine-devel/2004/11/0658.html (no comments) > Submitted to wine-patch: http://www.winehq.org/hypermail/wine-patches/2004/11/0327.html > Resubmitting against current CVS > > Changelog: > Ge van Geldorp <gvg(a)reactos.com> > - Generate and export stubs specified in .spec files for PE builds I don't think we want to add a special mode just for stubs; they should really be replaced by proper functions (even if the functions are stubs themselves, at least they can print the parameters and try to return something meaningful instead of killing the app). You can view the lack of stubs support on PE as an encouragement to help us remove them from the spec files ;-) -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Include file cleanup : dce.h

by Alexandre Julliard

Rémi Assailly <remi.assailly(a)free.fr> writes: > Changelog: > * get rid of dce.h > --- dlls/x11drv/winpos.c 2004-12-09 19:10:35.000000000 +0100 > +++ dlls/x11drv/winpos.c 2004-12-11 19:46:03.000000000 +0100 > @@ -40,7 +40,6 @@ > #include "x11drv.h" > #include "win.h" > #include "winpos.h" > -#include "dce.h" > #include "cursoricon.h" > #include "nonclient.h" > > @@ -49,6 +48,8 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(x11drv); > > +extern BOOL DCE_InvalidateDCE( HWND, const RECT* ); The goal of the header files cleanup is not to mechanically remove the #includes by duplicating the definitions, if we wanted to do that it would have been done long ago. The real goal is to get rid of the inter-dll dependencies, the global headers are really just a symptom of the problem. -- Alexandre Julliard julliard(a)winehq.org

Dec. 14, 2004

Re: Perform automatic bitmap font configuration based on the current locale

by Huw D M Davies

On Mon, Dec 13, 2004 at 11:39:58PM +0800, Dmitry Timoshkov wrote: > Hello, > > due to a GDI bug new values don't actually work, and that's another > thing I'm going to look at. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Perform automatic bitmap font configuration based on the current locale. > > diff -up cvs/hq/wine/dlls/kernel/locale.c wine/dlls/kernel/locale.c > --- cvs/hq/wine/dlls/kernel/locale.c 2004-11-22 17:52:19.000000000 +0800 > +++ wine/dlls/kernel/locale.c 2004-12-13 23:25:50.000000000 +0800 > @@ -5,6 +5,7 @@ > * Copyright 1998 David Lee Lambert > * Copyright 2000 Julio C?sar G?zquez > * Copyright 2002 Alexandre Julliard for CodeWeavers > + * Copyright 2003, 2004 Dmitry Timoshkov > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -226,25 +227,175 @@ inline static HKEY create_registry_key(v > { > static const WCHAR intlW[] = {'C','o','n','t','r','o','l',' ','P','a','n','e','l','\\', > 'I','n','t','e','r','n','a','t','i','o','n','a','l',0}; > - OBJECT_ATTRIBUTES attr; > - UNICODE_STRING nameW; > HKEY hkey; > > if (RtlOpenCurrentUser( KEY_ALL_ACCESS, &hkey ) != STATUS_SUCCESS) return 0; > > - attr.Length = sizeof(attr); > - attr.RootDirectory = hkey; > - attr.ObjectName = &nameW; > - attr.Attributes = 0; > - attr.SecurityDescriptor = NULL; > - attr.SecurityQualityOfService = NULL; > - RtlInitUnicodeString( &nameW, intlW ); > + return NLS_RegOpenSubKey( hkey, intlW ); > +} > > - if (NtCreateKey( &hkey, KEY_ALL_ACCESS, &attr, 0, NULL, 0, NULL ) != STATUS_SUCCESS) hkey = 0; > - NtClose( attr.RootDirectory ); > - return hkey; > +/*********************************************************************** > + * create_fonts_registry_key > + * > + * Create the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\\Fonts > + * registry subkey. > + */ > +inline static HKEY create_fonts_registry_key(void) > +{ > + static const WCHAR fontsW[] = { > + 'M','a','c','h','i','n','e','\\','S','o','f','t','w','a','r','e','\\', > + 'M','i','c','r','o','s','o','f','t','\\','W','i','n','d','o','w','s',' ','N','T','\\', > + 'C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\', > + 'F','o','n','t','s',0}; > + > + return NLS_RegOpenKey( 0, fontsW ); > } You should probably put them under HKLM\Software\Microsoft\Windows\CurrentVersion\Fonts too. (Or at least use this key for winver=win9x, since this is where we'll look if running in win9x mode). Huw. -- Huw Davies huw(a)codeweavers.com

Dec. 14, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by Ivan Leo Puoti

>I just tried Ivan's patch on my program, and get the same insufficient >version >error that I was getting with the original, unpatched, version. My >original patch did not have this problem. Why don't you add a few traces to see what's going on? I've already explained that your orginal patch is wrong. Also check the versions of the dlls that the function is calling, and the winver setting. Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 13, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by William Lahti

I just tried Ivan's patch on my program, and get the same insufficient version error that I was getting with the original, unpatched, version. My original patch did not have this problem. William

Dec. 13, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by Ivan Leo Puoti

> It was 4. Pehaps there is yet another bug someplace else. That's why in my updated patch I check the OS using the available info. It's here, you may want to try it out and check if it works for you app http://www.winehq.com/hypermail/wine-patches/2004/12/att-0275/01-wkivcf2.di… You patch was wrong because the fact that MajorSubsystemVersion is 4 and MinorOperatingSystemVersion is 0 doesn't mean the OS is win2k, it could be nt4 or win95, and returning win2000 when winver is set to win95 could cause problems. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/ba… Also it's better to use switch when comparing a variable to multiple values, it's more readable, and you added some useless braces. Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 13, 2004

wine loader bug

by Ivan Leo Puoti

I've got this strange error wine-pthread: virtual.c:703: map_file_into_view: Assertion `start + size <= view->size' failed. Aborted the wine loader seems unable to load the binary into memory, I tried commenting out the code between line 701 and 719 with #if 0, but that just caused a few compiler warnings and a segfault. I think I'll leave this to someone more skilled than me, if you want the binary that causes this drop me a line (And no I am not posting it to the list) Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 13, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by William Lahti

I actually test-ran my version of the patch with VB .NET's installer, which requires 2K or higher, where the other version was only compile-tested. It fixed the problem of the installer saying that I needed WIN2K or higher. I had actually tried exactly what Andreas Mohr had before coming up with the version I submitted, and it didn't work. My config file was set to emulate XP, so I echoed what MajorSubsystemVersion was. It was 4. Pehaps there is yet another bug someplace else. William Lahti

Dec. 13, 2004

Re: appdb bug

by tony_lambregts＠telusplanet.net

Ivan Leo Puoti wrote: > I can view the maintainers queue, and I can click on view, but I'm just > redirected to the queue again and can't approve maintainers. > > Ivan. Jonathan has a patch in the queue. Chris will probably apply it tonight sometime. There are some other bugs too. Screenshots page for one. -- Tony Lambregts

Dec. 13, 2004

appdb bug

by Ivan Leo Puoti

I can view the maintainers queue, and I can click on view, but I'm just redirected to the queue again and can't approve maintainers. Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 13, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Eric Pouech

Jonathan Gevaryahu a écrit : > Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: > >> To: Anish Mistry <mistry.7(a)osu.edu> >> Cc: wine-devel(a)winehq.org >> Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: >> breaks Total >> Annihilation >> >> and if you remove the entire line (if (!is_version_nt()) access = >> TIMER_ALL_ACCESS;)? >> A+ >> >> >> --__--__-- >> > > That doesn't fix the problem here. Still the same trace response... > I haven't run it enough times to see if it will still occasionally work > with that line altered or removed... I know it does work (without any > changes from the version in CVS) about 5% of the time. hmm it don't see where this could come from could someone of you try to apply the patch in parts (semaphore, event, timer, mutex), just to narrow a bit where this could come from A+

Dec. 13, 2004

Re: A new systray patch

by Shachar Shemesh

Mike Hearn wrote: >On Mon, 2004-12-13 at 20:16 +0200, Shachar Shemesh wrote: > > >>I'd love to get my digital camera syncing on Linux (Mustek). It uses a >>shell extension. Good enough reason for you? :-) >> >> > >Is a shell extension really the only way you can access the camera? >That's pretty poor UI design if so (imho :). > I no choice but to agree. It came in cheap, and I don't heavily rely on it. Otherwise I wouldn't have gone for anything short of a camera that acts as a USB storage device. >What desktop do you use, if any? > KDE. > Maybe we can add bridging shell >extensions to the list of fun tasks. > Hmm. Like I said in an earlier email, a shell extension (including a complete hand-coded OLE server) was my first Windows program ever. Since then (1996), however, I have done a lot of other stuff, and have blissfully wiped out most of the knowledge in that area. If I win the lottery (or enough people decide that I'm worthy of an award....), I /may/ pick something like that up. Until then, however, don't count on me. Just today I noticed that an edit control partial update optimization totally breaks BiDi display, so it's unlikely that my mainstream work will abate any time soon. As for the camera, USB support has to work before we can do anything with that. It will probably be simpler to get kamera to support the MDC 3000. If you reached this page through a search on the camera's support in Linux - just veer away from it. No optical zoom, all pictures taken relying mostly on the built-in flash overexpose. No reason to buy it unless you got it as a gift. >thanks -mike > > Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 13, 2004

Re: A new systray patch

by Mike Hearn

On Mon, 2004-12-13 at 20:16 +0200, Shachar Shemesh wrote: > I'd love to get my digital camera syncing on Linux (Mustek). It uses a > shell extension. Good enough reason for you? :-) Is a shell extension really the only way you can access the camera? That's pretty poor UI design if so (imho :). What desktop do you use, if any? Maybe we can add bridging shell extensions to the list of fun tasks. thanks -mike

Dec. 13, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Anish Mistry

On Monday 13 December 2004 02:27 am, Eric Pouech wrote: > and if you remove the entire line (if (!is_version_nt()) access = > TIMER_ALL_ACCESS;)? > A+ Nope, still the same problem. -- Anish Mistry

Dec. 13, 2004

Re: A new systray patch

by Shachar Shemesh

Mike Hearn wrote: > Shachar Shemesh wrote: > >> Though, if we would want to support shell extensions, I don't see how >> we could effectively do it without having it do everything the native >> explorer does.... > > > That would be the other reason. But, I think it makes more sense to > try and bridge shell extensions to Nautilus/Konqueror rather than > reimplement Explorer-the-file-manager. At least, that's what I'd try > first. > > Flip side is I'm not aware of any shell extensions people want to run > on Wine, at least, not yet ... I'd love to get my digital camera syncing on Linux (Mustek). It uses a shell extension. Good enough reason for you? :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 13, 2004

Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)

by Tero Tamminen

> What would be a shame again, we aren't particularly > overwhelmed with Win2k3 testers. Hope we can sort it out. > In the meantime just disable winrash if it's too disturbing, > I'll drop you a note once the necessary changes are in place. I have been looking from time to time the tests (it is interesting to see if there is development going on) and I haven't seen anybody else running tests in win2k3 than myself. Anyway, thanks for the help. I can run winrash from time to time, at least when I know that I am going to spend time on that box (more than just an occasional check). If new version comes out, I don't have to disable winrash and I can let it run all the time. -- Tero Tamminen Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

Dec. 13, 2004