March 2003 - Wine-devel - list.winehq.org

Re: WineHQ Idea
by Dimitrie O. Paun 24 Mar '03

24 Mar '03

On 20 Mar 2003, Jeremy Newman wrote: [I've Cc'ed wine-devel since I've just reposted the questions there] > On Thu, 2003-03-20 at 15:57, Dimitrie O. Paun wrote: > > I was looking at the main page of the new WineHQ, and I was thinking > > of the following changes: > > 1. The menu at the bottom of the main "About" box is mainly > > duplicating the the left-side menu. Let's get rid of it. > > In this case I think the duplication is good. From a newbie aspect, the > first place they will read is the text on the home page. And the extra > clarification helps. This is a good point, but I feel that the benefit is not worth the cost. It takes up a lot of space, and really the _same_ options are available on the _same_ page. What kind of newbie are we talking about that can read "News" in one place, but can't read the exact same word 2 inches to the right? We are light years clean / simpler navigation than the old site, lets not exagerate. > > 2. Move the theme selector somewhere else, like another box on > > on the left, below "Developemnt" > > Yeah, for this beta, its there for now, I think I will make a > "Preferences" link somewhere in the nav. That's cool. > > 3. In place of the "Change Theme" box, let's have an "Announcements" > > box (like the KDE/GNOME/etc pages) where we can place the > > latest and greatest things, such as Wine releases, News releases, > > interviews, etc. > > See, that would be duplication. We already have news. It's WWN. Adding > announcements that don't get updated as often as WWN seems lame. Leave > that to other news sites. I beg to differ. WWN is more like a magazine. It is wandeerful, and has a good purpose, but that it's not for announcement. People don't wait a month to read the latest news, they watch TV or read the newspaper. The WWN appears weekly (sometime lest often), and is concerned mainly with development topics). An Announcement section would be updated whenever something important (from a user standpoint) happens: -- A new Wine version is released -- A new WWN is released -- An important event happened in the community So the two differ in all aspects (WWN vs. Announcements) 1. Audience: Developers vs. Users 2. Update Strategy: Weekly vs. Real Time 3. Content Focus: Development Issues vs. Events And the proof is in the pudding: most major project sites have different sections for the two. See www.gnome.org, www.kde.org, www.gimp.org, etc. For better or worse, people _expect_ things organized in a certain way. Like the "File" menu to the left. Even if we think our idea are better, we should follow the Principle of Least Surprise in these matters, unless we can make a _strong_ case against it. In this instance, it seems to me it makes sense to follow the status quo. -- Dimi.

4 12

Another minor bug
by Steven Edwards 24 Mar '03

24 Mar '03

I dont have time to patch this right now but maybe someone else does. When building import libs on mingw because we have to link to libwine in winebuild for wine_get_cs winebuild cant find libwine.dll. $ make PATH="../libs/unicode:$PATH" ../tools/winebuild/winebuild -o advapi32/advapi32. spec.def --def advapi32/advapi32.spec make: *** [advapi32/advapi32.spec.def] Error 128 Thanks Steven

1 0

re: Wine and glibc 3.2.x
by Dan Kegel 24 Mar '03

24 Mar '03

davide.giannotti(a)itsplanet.com wrote: > Ok, i recently compiled and upgraded to glibc 3.2.1 and there's no way to make > wine work. There's thread related bug. > New Red Hat, Suse and Mandrake will be shipped with this new version of glibc, > so i think that's a serious bug. We were all quite concerned about it until somebody reported a workaround; see http://www.winehq.com/hypermail/wine-devel/2003/02/0260.html The workaround is to give the command export LD_ASSUME_KERNEL=2.2.5 before running Wine (and probably before running configure, too). (This is documented in each distro's beta release notes, e.g. http://distro.ibiblio.org/pub/Linux/distributions/redhat/beta/phoebe/en/os/… ) Have you tried this yet? What CPU and OS are you using? > Configure cannot even check that libc are reentrant, i'm not a glibc expert > but there's some error with _errno and _errno_location. > I tried to apply a patch i found in the patch mailing list, but it didn't work > either. > ( http://www.winehq.com/hypermail/wine-patches/2003/01/0338.html ) That patch was bogus, it is not the right fix. The right fix is for Wine to adapt to the new threading model in glibc2.3 (not 3.2, I think), which is far superior to the old one. See http://www.kegel.com/c10k.html#threads.nptl > So, consider that every linux distribution will be shipped with the new glibc, > and that there will be really a few windows programs that can work without > thread support.... well... i'd think about give priority to solve this one. The changes needed are deep. Alexandre has started on them, but given the workaround, it can probably wait a bit. See also http://www.winehq.com/hypermail/wine-devel/2003/02/0252.html http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83254 http://redhat.ifsic.univ-rennes1.fr/_rawhide/glibc-devel-2.3.1-51.i386.html -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 12

nvidia crashes?
by Mike Hearn 24 Mar '03

24 Mar '03

Hi, Often when a program fails, I'll get a crash inside libGLcore (with the nvidia drivers), backtrace looks like: (gdb) bt #0 0x40e0a208 in __nvsym12888 () from /usr/lib/libGLcore.so.1 #1 0x00001a76 in ?? () #2 0x4202b162 in exit () from /lib/i686/libc.so.6 #3 0x400ab79f in ExitProcess () at ../../scheduler/process.c:1440 #4 0x0100279b in ?? () #5 0x400a95a6 in start_process () at ../../scheduler/process.c:566 #6 0x400ad8bd in call_on_thread_stack (func=0x400a936c) at ../../scheduler/sysdeps.c:107 so I think it's hooking into the exit chain. I'm not sure why it'd crash like this, I haven't touched my video configuration for a while, and everything else seems stable. Is there any way to stop wine from loading opengl related code? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: windres: serious bug
by Dimitrie O. Paun 24 Mar '03

24 Mar '03

On March 21, 2003 05:55 am, Nick Clifton wrote: > Just to be clear ... Dimitrie, please could you try Ian's patch and > provide us with feedback as to how well it works. This would not > violate copyright restrictions (provided that you do not post any > code), and since you are actually using this tool, you are the one > most like likey to be able to verify that the patch is working > properly. Well, certainly. To be honest, the situation is a bit more complicated. I haven't been doing any active work on the Mozilla port, my interest in the port is as a starting base for a port to Wine. This may sound odd, but for various reasons (of which just being cool is not least important), I'd like to compile the Win32 port of Mozilla under Wine in Linux. Needless to say, such ports are not trivial, but I set out to make them a lot simpler, so that we make it practical for people to port their Win32 app to Linux via Winelib. To that end I started created a MinGW-compatible build environment in Wine. Thus, porting to Wine will become a two step process: first port to MinGW, then port to Wine. It is easy to see that this approach is a lot more evolutionary, and the steps are simpler. Moreover, you have intermediate working code (the mingw port) which is also very important, not to mention that smaller number of things that change from under you in each step (in the mingw port, you only have to deal with the build tools changing, while the wine port, given that I can provide mingw-compatible tools in Wine, it's just the OS that changes). Ideally, if everything works according to the plan, the above process looks like so: A. Port MSVC/BCC app to MinGW 1. Create GNU Makefiles 2. Deal with difference between cl/bcc and gcc 3. Get working versions of the app under MinGW B. Port from MinGW to Wine 1. Copy source code to a Linux box, run dos2unix on it 2. Change #include directives from #include "some\dir\file.h" to #include "some/dir/file.h" 3. Change file/dir name capitalization to match the one on disk NOTE: Changed (2) & (3) are scriptable, and we already have a tool that takes care of them. Most importantly, they are portable between all ports so a common source code can be maintained. Needless to say, this is paramount, few people have the resources to maintain different sources. 4. Change the Makefile as follows: + ifndef WINE CC = gcc CXX = g++ WRC = windres + else + CC = winegcc + CXX = wineg++ + WRC = wrc + endif Again this change is portable between ports, so a common build system can be maintained. The winegcc/wineg++ tools already work, but they are not ready. They mainly lack -shared support for generating DLLs, but they already proved useful in porting a number of apps (http://24.103.33.114/wine/Winelib-Apps.html) or toolkits (http://www.dssd.ca/wine/Wine-Fun.html#wxwindows) This should give people a better idea why I think command line compatibility between tools is important. However, to get back to the topic of this message, I was interested in the Mozilla port to MinGW only as a starting point form my efforts toward a Winelib port. As such I haven't actually worked on it, so I don't have the environment handy to test the changes. I've posted the patch to the Mozilla bug, and hopefully someone will give it a try. If not, I'll test it, but it will take a little while to get everything up to speed. Another way is to post a test .rc file that was experiencing the problem before, would that be useful? -- Dimi.

2 4

Thunking?
by Mike Hearn 24 Mar '03

24 Mar '03

Hi, Does anybody know what could cause this error? err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 I checked, I don't haev comctrl.dll anywhere. I'm trying to get IE6 to work on an "out-of-the-box" Wine install, ie trying to move to a completely WineHQ setup rather than the winehq/crossover setup I was using before. I was under the impression that thunking was only used for 32/16 bridging, and IE6 is a 32bit app, so I don't really understand why it's trying to load this library using LoadLibrary16... does anybody have some tips? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

Error in CVS
by Vilppa Salt 24 Mar '03

24 Mar '03

When running ./configure with latest cvs Wine: <snip> config.status: creating dlls/ctl3d/Makefile config.status: creating dlls/d3d8/Makefile config.status: creating dlls/d3dim/Makefile config.status: creating dlls/d3dx8/Makefile config.status: creating dlls/dciman32/Makefile config.status: creating dlls/ddraw/Makefile config.status: creating dlls/devenum/Makefile config.status: creating dlls/dinput/Makefile config.status: creating dlls/dinput8/Makefile config.status: creating dlls/dmusic/Makefile config.status: error: cannot find input file: dlls/dmusic/Makefile.in --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

3 2

Janitorial W->A dlls/gdi/printdrv.c (help!)
by Tony Lambregts 24 Mar '03

24 Mar '03

I have been banging my head against this one for a while and need some feedback about a problem I am having. I have attached the patch to convert StartDocA to call StartDocW instead of the other way around. This patch results with StartDocW looking as follows INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc) { INT ret = 0; DC *dc = DC_GetDCPtr( hdc ); TRACE("DocName = '%s' Output = '%s' Datatype = '%s'\n", debugstr_w(doc->lpszDocName), debugstr_w(doc->lpszOutput), debugstr_w(doc->lpszDatatype)); if(!dc) return SP_ERROR; if (dc->funcs->pStartDoc) ret = dc->funcs->pStartDoc( dc->physDev, doc ); GDI_ReleaseObj( hdc ); return ret; } The problem I am having is with this line. if (dc->funcs->pStartDoc) ret = dc->funcs->pStartDoc( dc->physDev, doc ); With my patch in place I get the following error printdrv.c: In function `StartDocW': printdrv.c:82: warning: passing arg 2 of pointer to function from incompatible pointer type so obviously dc->funcs->pStartDoc points to a function that expects DOCINFOA* as its second parameter but I am at a loss on what to do. I have tried to trace down where "DC_GetDCPtr( hdc )" gets this information but I just ended up confused. Please help! -- Tony Lambregts Index: printdrv.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v retrieving revision 1.30 diff -u -u -r1.30 printdrv.c --- printdrv.c 22 Nov 2002 22:16:53 -0000 1.30 +++ printdrv.c 23 Mar 2003 20:36:11 -0000 @@ -48,6 +48,7 @@ #include "gdi.h" #include "heap.h" #include "file.h" +#include "winternl.h" WINE_DEFAULT_DEBUG_CHANNEL(print); @@ -58,7 +59,7 @@ /****************************************************************** - * StartDocA [GDI32.@] + * StartDocW [GDI32.@] * * StartDoc calls the STARTDOC Escape with the input data pointing to DocName * and the output data (which is used as a second input parameter).pointing at @@ -67,13 +68,14 @@ * * Note: we now do it the other way, with the STARTDOC Escape calling StartDoc. */ -INT WINAPI StartDocA(HDC hdc, const DOCINFOA* doc) +INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc) { INT ret = 0; DC *dc = DC_GetDCPtr( hdc ); TRACE("DocName = '%s' Output = '%s' Datatype = '%s'\n", - doc->lpszDocName, doc->lpszOutput, doc->lpszDatatype); + debugstr_w(doc->lpszDocName), debugstr_w(doc->lpszOutput), + debugstr_w(doc->lpszDatatype)); if(!dc) return SP_ERROR; @@ -83,32 +85,27 @@ } /************************************************************************* - * StartDocW [GDI32.@] + * StartDocA [GDI32.@] * */ -INT WINAPI StartDocW(HDC hdc, const DOCINFOW* doc) +INT WINAPI StartDocA(HDC hdc, const DOCINFOA* doc) { - DOCINFOA docA; - INT ret; - - docA.cbSize = doc->cbSize; - docA.lpszDocName = doc->lpszDocName ? - HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszDocName ) : NULL; - docA.lpszOutput = doc->lpszOutput ? - HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszOutput ) : NULL; - docA.lpszDatatype = doc->lpszDatatype ? - HEAP_strdupWtoA( GetProcessHeap(), 0, doc->lpszDatatype ) : NULL; - docA.fwType = doc->fwType; - - ret = StartDocA(hdc, &docA); - - if(docA.lpszDocName) - HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszDocName ); - if(docA.lpszOutput) - HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszOutput ); - if(docA.lpszDatatype) - HeapFree( GetProcessHeap(), 0, (LPSTR)docA.lpszDatatype ); - + DOCINFOW docW; + int ret; + UNICODE_STRING DocName, Output, Datatype; + + docW.cbSize = doc->cbSize; + RtlCreateUnicodeStringFromAsciiz(&DocName, doc->lpszDocName); + RtlCreateUnicodeStringFromAsciiz(&Output, doc->lpszOutput ); + RtlCreateUnicodeStringFromAsciiz(&Datatype, doc->lpszDatatype ); + docW.lpszDocName = DocName.Buffer; + docW.lpszOutput = Output.Buffer; + docW.lpszDatatype = Datatype.Buffer; + docW.fwType = doc->fwType; + ret = StartDocW(hdc, &docW); + RtlFreeUnicodeString(&DocName); + RtlFreeUnicodeString(&Output); + RtlFreeUnicodeString(&Datatype); return ret; }

2 3

Re: Janitorial W->A cleanup objects/metafile.c dlls/gdi/mfdrv/init.c
by Dmitry Timoshkov 24 Mar '03

24 Mar '03

"Tony Lambregts" <tony_lambregts(a)telusplanet.net> wrote: > This one was required more that a mop and pail. In the end what I had to do is > convert MF_CreateMetaHeaderDisk to unicode. > > One burning question I have at this point is the relative merits of using > RtlCreateUnicodeStringFromAsciiz vs MultiByteToWideChar MultiByteToWideChar uses Rtl* functions internally and using ntdll APIs directly should give a slightly better performance. RtlCreateUnicodeStringFromAsciiz also is supposed to hide the internals of the conversion and help to avoid bugs and typos. > @@ -62,7 +65,7 @@ > { > DWORD dw1, dw2, dw3; > WORD w4; > - CHAR filename[0x100]; > + WCHAR filename[MAX_PATHNAME_LEN]; Please do not increase the buffer size if there is no real need for it. MAX_PATHNAME_LEN = 1024. It's better though to replace 0x100 by MAX_PATH IMO. > } METAHEADERDISK; > #include "poppack.h" > > @@ -350,9 +353,9 @@ > ERR("Not a disk based metafile\n"); > return NULL; > } > - mhd = (METAHEADERDISK *)((char *)mh + sizeof(METAHEADER)); > + mhd = (METAHEADERDISK *)((WCHAR *)mh + sizeof(METAHEADER)); Wrong. > @@ -377,8 +380,8 @@ > sizeof(METAHEADER) + sizeof(METAHEADERDISK)); > mh->mtType = METAFILE_DISK; > size = HeapSize( GetProcessHeap(), 0, mh ); > - mhd = (METAHEADERDISK *)((char *)mh + sizeof(METAHEADER)); > - strcpy(mhd->filename, filename); > + mhd = (METAHEADERDISK *)((WCHAR *)mh + sizeof(METAHEADER)); Wrong again. -- Dmitry.

2 2

ImageList - my findings
by Vitaliy Margolen 24 Mar '03

24 Mar '03

For past few days I was trying to figure out what is the problem with corrupt bitmaps. Here is my findings: 1. _read_bitmap does is not work right. The for() loop where it's restructuring original bitmap from multi-row into single-row. 2. Windows creates DIBSection to keep original bitmap so it could be saved as is. This is not used that often. However development tools do use it. For example: Delphi. I have few questions before making any hacking: - Why do we use single row bitpams versus multi-row like native? - Why we not creating DIBSection? -- Best regards, Vitaliy Margolen

4 5