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

Re: Add some exports to NtDll and AdvApi32
by Alexandre Julliard 30 Oct '03

30 Oct '03

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > Changelog: > - Add some stub exports to spec files for NtDll and AdvApi As a rule, for functions that only exist in later Windows versions, it's better to add them commented out, so that apps don't try to call the stubs. We should only add a real stub if an app links against it directly. -- Alexandre Julliard julliard(a)winehq.com

1 0

Useful article on x86 disassembly skills
by Mike Hearn 30 Oct '03

30 Oct '03

After finding that COM article, I decided to dig my way through the backissues of MSJ to see what other gems I could uncover. Here's one useful one: http://www.microsoft.com/msj/0298/hood0298.aspx It is a basic introduction to x86 assembly from a reverse engineers point of view. Most of it is basic stuff you probably know already, however there are some useful bits there - for instance, it took me some time before I figured out that "xor eax, eax" was being used to clear the register because it led to smaller code size whereas this article tells you about that and similar tricks so it's easier to read optimized code. It also gives you some useful constructs that access the TEB, for instance now I know that these fs:[00000000] things are setting up new SEH frames. A worthwhile read for times when disas is the only way forward.... thanks -mike

1 0

Wine coredumps with Linux kernel 2.6.0-test9
by David D. Hagood 30 Oct '03

30 Oct '03

I'm playing with 2.6.0-test9 under RH9.0, and Wine just coredumps when I run it. This is after a full rebuild of Wine, with a CVS pull of a couple of days ago. Since I've seen some other apps behaving weirdly this may be a compatibility issue with 2.6, but I thought I'd see if anybody else has seen this, and has any suggestions. I have updated glibc to the latest in Rawhide.

3 4

Re: getting started with Winelib
by Ralf Juengling 30 Oct '03

30 Oct '03

Okay, I got it to compile by manipulating the Makefile.in (kicking some *.rc files). But the executable segfaults: [juenglin(a)alpspitze winemine]$ make sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in >wineapploader || rm -f wineapploader LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/wrc -I. -I/local/include/wine/windows -o rsrc.res rsrc.rc gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o dialog.o dialog.c gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o main.o main.c gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o winemine.exe.dbg.o winemine.exe.dbg.c LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/winebuild -fPIC -o winemine.exe.spec.c --exe winemine.exe -mgui rsrc.res dialog.o main.o winemine.exe.dbg.o -L/local/lib/wine -L/local/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o winemine.exe.spec.o winemine.exe.spec.c gcc -shared -Wl,-Bsymbolic -o winemine.exe.so dialog.o main.o winemine.exe.dbg.o winemine.exe.spec.o -L/local/lib -lwine -lwine_unicode -lwine_uuid -lm test -f winemine || install wineapploader winemine [juenglin(a)alpspitze winemine]$ winemine Segmentation fault Might this be a configuration problem, or is something broken in Winelib? Since I have no root account, I had to skip the invocation of /sbin/ldconfig when installing wine-20031016. So I set LD_LIBRARY_PATH to /local/lib:/local/lib/wine. Any help appreciated, Ralf On Mon, 2003-10-27 at 18:23, Ralf Juengling wrote: > On Mon, 2003-10-27 at 13:09, Alexandre Julliard wrote: > > Ralf Juengling <juenglin(a)cse.ogi.edu> writes: > > > > > So there is nothing I can do about it at the moment? > > > What is the most recent Wine version in which winemaker used to work? > > > > The previous release should work. Or try this patch: > > > > Index: tools/winemaker > > =================================================================== > > RCS file: /opt/cvs-commit/wine/tools/winemaker,v > > retrieving revision 1.65 > > diff -u -p -r1.65 winemaker > > --- tools/winemaker 5 Aug 2003 18:31:32 -0000 1.65 > > +++ tools/winemaker 27 Oct 2003 21:07:38 -0000 > > @@ -2769,14 +2769,10 @@ then > > WINE_DLL_ROOT="/lib:/lib/wine:/usr/lib:/usr/lib/wine:/usr/local/lib:/usr/local/lib/wine" > > fi > > fi > > -AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.dll.so],[ > > - AC_MSG_ERROR([Could not find the Wine dlls (libntdll.dll.so)]) > > +AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.def],[ > > + AC_MSG_ERROR([Could not find the Wine dlls (libntdll.def)]) > > ],[$WINE_DLL_ROOT]) > > - > > -AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll.dll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ > > - AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.dll.so)]) > > -],[$WINE_DLL_ROOT]) > > -WINE_DLL_PATH="-L$WINE_DLL_ROOT/wine" > > +WINE_DLL_PATH="-L$WINE_DLL_ROOT" > > > > if test -z "$WINE_TOOL_PATH" > > then > > Thanks, together with the patch > > --- /local/downloads/wine-20031016/tools/winemaker 2003-10-27 > 18:02:41.000000000 -0800 > +++ /local/bin/winemaker 2003-10-27 18:14:22.000000000 -0800 > @@ -2635,7 +2635,7 @@ > WINE_UNICODE_ROOT="$WINE_ROOT:$WINE_ROOT/lib:$WINE_ROOT/unicode" > WINE_UUID_ROOT="$WINE_ROOT:$WINE_ROOT/lib:$WINE_ROOT/ole" > > WINE_TOOL_PATH="$WINE_ROOT:$WINE_ROOT/bin:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild" > - WINE_DLL_ROOT="$WINE_ROOT/dlls:$WINE_ROOT/lib" > + WINE_DLL_ROOT="$WINE_ROOT/dlls:$WINE_ROOT/lib:$WINE_ROOT/lib/wine" > fi > > AC_ARG_WITH(wine-includes, > > > the generated configure script does its job without errors. > Now I the following error from make: > > [juenglin(a)alpspitze winemine]$ make > sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' > ./wineapploader.in >wineapploader || rm -f wineapploader > LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/wrc -I. > -I/local/include/wine/windows -o En.res En.rc > En.rc:23:22: Error: parse error > make: *** [En.res] Error 1 > > > > -- Ralf Juengling <juenglin(a)cse.ogi.edu>

1 0

compiling winemine resources
by Ralf Juengling 30 Oct '03

30 Oct '03

I was not successful with compiling the winemine application in wine-20031016. When the resource compiler is to compile one of the language dependent files, it issues a 'parse error': [juenglin(a)alpspitze winemine]$ wrc En.rc En.rc:23:22: Error: parse error Line 23 in En.rc reads LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US So it looks like wrc does not know what to do with the constant LANG_ENGLISH. Is this a bug? Any idea whats going wrong here? Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

2 2

Where do old rpms go
by Bill Medland 30 Oct '03

30 Oct '03

I apologise for not concentrating; I'm sure that someone has already answered this but I can't find the answer. Do the rpms at SourceForge expire? (I see that the 20030618 for RedHat are no longer there) I just want to know since if that is the case I will have to start taking copies. On the same subject, does anyone have a consistant SuSE 8.1 rpm of the 20030618 version? (That's the last version that worked well for our InstallShield and I don't have time to try to figure out what broke) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

3 3

Re: Another symbol font fix
by Huw D M Davies 30 Oct '03

30 Oct '03

On Wed, Oct 29, 2003 at 08:23:16PM +0100, Rein Klazes wrote: > Hi, > > There are a couple of non-MS TT fonts on my system that only display > rectangles in win98's charmap.exe. Wine recognize these to have a SYMBOL > character set but Windows (win2k) does not. So libfreetype returning a > character mapping ft_encoding_symbol is not enough, I propose testing > the 0xf000 character offset that is assumed in other parts of the code. > > Tested to work for libfreetype 2.0.9 and 2.1.5 This sounds strange. Is there any chance that you could send me the font? Failing that could you send me the output of ftdump? Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Re: winetests: new addition
by Ferenc Wagner 30 Oct '03

30 Oct '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I'm still not sure how to support building with PE .exes Could you outline the problems you can see? Since it is still not in the tree, instead of patches I send comments and questions. > +#include <shellapi.h> > +#include <shellapi.h> Do we really need it twice? > + while (1) > + { > + va_start(ap, fmt); > + n = vsnprintf (p, size, fmt, ap); > + va_end(ap); > + if (n > -1 && n < size) return p; > + size = min( size*2, n+1 ); > + if(!(p = realloc (p, size))) fatal("Out of memory."); > + } MSDN has no vnsprintf() only _vsnprintf(), what is this? The size=min(...) does not make sense for me either. va_start and va_end could be moved out of the loop by using break instead of return. > +int print_version(FILE *fout) > +{ > + OSVERSIONINFOEX ver; > + > + ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); > + if (!GetVersionEx ((OSVERSIONINFO *) &ver)) > + { > + ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > + if (!GetVersionEx ((OSVERSIONINFO *) &ver)) > + return 0; This should be made a fatal(), I think. > + } > + fprintf(fout, " dwMajorVersion=%ld\n dwMajorVersion=%ld\n" The second is dwMinorVersion. > +void deletePath( char *path ) > +{ > + SHFILEOPSTRUCT fileop; > + > + path[strlen( path ) + 1] = '\0'; We do not have space allocated for this NUL. Here we use the advanced Shell API but later not the Win32 API for opening files and such. What is our policy? > +int count_tests() This is superfluous, not used for anything particularly useful. The progress bar still did not make it... > + if((fout = fopen(test->exename, "wb"))) > + { > + fwrite(code, size, 1, fout); > + fclose(fout); > + } No error checking whatsoever... > + char line[512], *cmd; Fixed size buffers are wrong... > + if ((fp = popen( cmd, "r" ))) > + { > + while (fgets( line, sizeof(line), fp )) > + fprintf( logfp, "%s", line ); > + fclose( fp ); > + } Why not a CreateProcess with redirected stderr/stdout? > + if (!(fp = fopen( logfile, "w" ))) fatal("Could not open log file."); Why not append mode? That would also make the above redirection more secure. > + for(test = wine_tests; test->name; test++) The number of tests could be determined by sizeof instead of a special member, but I am not sure that would be worth it. > +BINDIR="../.." [...] > +for test in $TEST_EXES; do > + testname=`basename $test .exe` > + filename="$BINDIR/$test.so" I am probably too tired, but can not see how you find the test .so-s in the dlls directory... So I am back, and ready to go for finishing this project... Feri.

4 10

Int21 bug
by Valentijn Sessink 30 Oct '03

30 Oct '03

Hi folks, I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists this is 91 decimal). My older version of wine, 2000821, goes like this: trace:int21:DOS3Call CREATE NEW FILE 0x00 for X:\TMP41.$$$ trace:file:CreateFileA X:\TMP41.$$$ GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW trace:dosfs:DOSFS_GetFullName X:\TMP41.$$$ (last=0) trace:string:lstrcpynA (0x40e35fa0, "/tmp", 1024) trace:dosfs:DOSFS_FindUnixName /tmp,TMP41.$$$ trace:heap:HeapAlloc (403c0000,00000002,0000022c): returning 414c9cf4 trace:heap:HeapAlloc (65430000,04000000,00000018): returning 65432c30 warn:dosfs:DOSFS_FindUnixName 'TMP41.$$$' not found in '/tmp' trace:heap:HeapFree (65430000,04000000,65432c30): returning TRUE trace:heap:HeapFree (403c0000,00000002,414c9cf4): returning TRUE trace:dosfs:DOSFS_GetFullName returning /tmp/TMP41.$$$ = X:\tmp41.$$$ 080732c8: create_file( access=c0000000, inherit=0, sharing=00000003, create=1, attrs=00000000, filename="/tmp/TMP41.$$$" ) 080732c8: create_file() = 0 { handle=136 } trace:file:FILE_AllocDosHandle Got 10 for h32 136 trace:int21:DOS3Call returning: AX=000a BX=5b0c CX=0000 DX=e9a8 SI=0000 DI=e9a8 DS=0a27 ES=0907 EFL=00000202 trace:global:GlobalHandle16 0107 Ret KERNEL.102: DOS3CALL() retval=none ret=0347:2513 ds=0a27 AX=000a BX=5b0c CX=0000 DX=e9a8 SI=0000 DI=e9a8 ES=0907 EFL=00000202 trace:global:GlobalHandle16 0107 So: file handle 0x136 translates to DOS handle 10, and int21 returns AX=0x000a My newer version, Wine 20030408, does the following: 000a:trace:int21:INT_Int21Handler CREATE NEW FILE 0x00 for X:\TMP18467.$$$ 000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000020): returning 415b32c0 000a:trace:file:CreateFileW L"X:\\TMP18467.$$$" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW attributes 0x0 000a:trace:dosfs:DOSFS_GetFullName L"X:\\TMP18467.$$$" (last=0) 000a:trace:string:lstrcpynA (0x40f40d84, "/tmp", 1024) 000a:trace:dosfs:DOSFS_FindUnixName /tmp,L"TMP18467.$$$" 000a:trace:dosfs:DOSFS_ToDosFCBFormat (L"TMP18467.$$$", 0x40f40ce4) 000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000110): returning 415cc890 000a:trace:dosfs:DOSFS_OpenDir "/tmp" 000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000018): returning 415cbca0 000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000210): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000410): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000810): returning 415cc890 000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00001010): returning 415cc890 000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415cbca0): returning TRUE 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) 000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".font-unix", short_name: (null) [cut directory listing] 000a:warn:dosfs:DOSFS_FindUnixName L"TMP18467.$$$" not found in '/tmp' 000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415cc890): returning TRUE 000a:trace:dosfs:DOSFS_GetFullName returning /tmp/TMP18467.$$$ = L"X:\\tmp18467.$$$" 000a:trace:dosfs:GetDriveTypeW (L"X:\\tmp18467.$$$") 000a: create_file( access=c0000000, inherit=0, sharing=00000003, create=1, attrs=00000000, drive_type=3, filename="/tmp/TMP18467.$$$" ) 000a: create_file() = 0 { handle=0x98 } 000a:trace:file:CreateFileW returning 0x98 000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415b32c0): returning TRUE 000a:trace:file:Win32HandleToDosFileHandle Got 10 for h32 0x98 000a:Ret kernel32.INT_Int21Handler() retval=00000000 ret=41560c39 000a:trace:int21:DOSVM_Int21Handler failed, error 0 000a:trace:int21:DOSVM_Int21Handler returning: AX=0000 BX=5b0f CX=0000 DX=e9a8 SI=0000 DI=e9a8 DS=0a47 ES=0927 EFL=00000203 000a:Ret winedos.CallBuiltinHandler() retval=0000007c ret=4008d9f0 000a:trace:global:GlobalHandle16 011f This seems weird: there's a file handle, there's a DOS file handle but Int21 returns AX=0, indicating an error. I did not yet check the code (will do this afternoon, but beware: I'm not much of a coder), but I think a fix should be rather easy, there's probably just a typo (or a thinko) in the Int21 handler. I'm not sure, but this bug could also help number 1170, that seems related in that there's a file that is not actually there, and 717, which also tries to make a file that isn't created. Please Cc: my e-mail-address as I'm not on the Wine-devel list. the "nospam" part has an MX record, so mailing shouldn't be a problem. We also checked Codeweavers Wine for this bug; it seems to be there, but after two days of bug hunting our hunting ground is a bit of a mess, so I'm not sure if we tested 2.0 or 2.1. I searched Bugzilla for a DOS related bug and couldn't find one, but if it's fixed between 20030408 and now, then please accept my apologies for wasting your precious reading time. Best regards, Valentijn

3 3

make install problem
by Dimitrie O. Paun 29 Oct '03

29 Oct '03

Hi folks, We have a problem with 'make install' in the libs dir. More explicitly, after a 'make & make install', I have this in /usr/local/lib: [dimi(a)dimi unicode]$ ls -l /usr/local/lib/libwine* -rw-r--r-- 1 root root 319332 Oct 27 12:01 /usr/local/lib/libwine_port.a lrwxrwxrwx 1 root root 14 Oct 28 14:38 /usr/local/lib/libwine.so -> libwine.so.1.0 -rwxr-xr-x 1 root root 249859 Oct 28 14:37 /usr/local/lib/libwine.so.1 -rwxr-xr-x 1 root root 238529 Feb 20 2003 /usr/local/lib/libwine.so.1.0 lrwxrwxrwx 1 root root 22 Oct 28 14:38 /usr/local/lib/libwine_unicode.so -> libwine_unicode.so.1.0 -rwxr-xr-x 1 root root 1289718 Oct 28 14:37 /usr/local/lib/libwine_unicode.so.1 -rwxr-xr-x 1 root root 1187040 Feb 20 2003 /usr/local/lib/libwine_unicode.so.1.0 -rw-r--r-- 1 root root 1867136 Oct 28 14:37 /usr/local/lib/libwine_uuid.a That is to say, both libwine.so and libwine_unicode.so are fubared. They point to old libs. Shouldn't they just point to the .1 versions? It's true, I didn't do a 'make install-dev', but this is counter intuitive because 'make install' does install the headers, and libwine_uuid.a, and libwine_port.a, and winegcc, and so on. -- Dimi.

3 4