wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

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@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@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

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@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

Installshield7 notes
by Carlos Lozano 29 Oct '03

29 Oct '03

Hello, Here goes some notes about how to install installshield 7 programs with the actual wine releases (sorry, i haven't been able to install without some natives DLLs). You need 3 native DLLs (ole32.dll, oleaut32.dll and rpcrt4.dll), and 2 .tlb files (stdole32.tlb and stdole2.tlb). Copy this 5 files to your windows/system directory, and edit your ~/.wine/config, using: [DllOverrides] "oleaut32" = "native" "ole32" = "native" "rpcrt4" = "native" Even using this natives dlls, you will have problems with the windows order, what you will not leave you see the windows and install the program. The easier way to install it, should be enable the Desktop mode, in ~/.wine/config: "Managed" = "N" "Desktop" = "640x480" "Desktop" = "Y" I have found some programs, what give problems with Desktop mode, exiting during install with X11 errors (Praetoriams demo for example). In this cases you can use yet another trick. Disable Desktop, and enable "Managed" = "Y", then in the file the file "dlls/x11drv/window.c", you will find the function "inline static BOOL is_window_managed( WND *win )", in the end of this function, there are this 3 lines: /* default: not managed */ return FALSE; } replace, "return FALSE;" to "return TRUE;", and run make install again. Remember after of install the program change again this line to "FALSE", because you could have problems later with other windows. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

2 1

Int21 bug
by Valentijn Sessink 29 Oct '03

29 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

Re: [dx88] Cull fix
by MichaelGuennewig＠gmx.de 29 Oct '03

29 Oct '03

Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > Michael - See if this helps with your map / figure problems... Sorry, but it doesn't helped. Also the other ones doesn't helped. The fixme's fixme:d3d_surface:IDirect3DSurface8Impl_LockRect fixme:d3d:IDirect3DDevice8Impl_SetRenderTarget fixme:d3d:IDirect3DDevice8Impl_ResourceManagerDiscardBytes also still appear as before. Do you want a new "-debugmsg +d3d8,+d3d_surface" log or pherhaps the texture snapshots? But I couldn't create any of them before next week, because I'm going sailing over the weekend. Michael

1 0

Forwards exports - anyone?
by Shachar Shemesh 29 Oct '03

29 Oct '03

Hi all, I noticed in the code that there is a concept called "forwad_export". Does it have anything to do with making a function in one DLL return a function address that belongs to another? If that is the case, how do I activate this? Is there some spec file magic that will do it? I'm trying to implement unicows.dll. The theory is quite simple - since unicows merely implements unicode functions that exist, theoretically, only in Wine, all I have to do is create forwards (i.e. - ExtTextOutW in unicows.dll will call ExtTextOutW in GDI). This is slightly inefficient, but should solve our unicows.dll problems. If I can merely instruct the dynamic loader to return the GDI ExtTextOutW function when someone tries to link with the unicows ExtTextOutW, I can solve the inefficiency in a clean, working way without further problems. I considered various loader tricks, but I'm afraid the closest I'm willing to come is assembler tricks, and those won't work on other platforms (then again - other platforms are highly unlikely to require unicows - hmm). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

2 1

RE: How do i find the start menu path?
by Rolf Kalbermatter 29 Oct '03

29 Oct '03

Robert van Herk <robert(a)robertvanherk.nl> wrote: >I have a question for my start menu generator, that is almost finished >now... > >How do I find the path of the wine start menu? (for me it's >~/c/windows/Start Menu, but for someone else it does not have to be like >that...) I assume/hope you have a winelib app in which case you can just simply call ret = SHGetSpecialFolderPathW(NULL, lpString, CSIDL_PROGRAMS, FALSE); and unless SHRestricted(REST_NOCOMMONGROUPS) is true also ret = SHGetSpecialFolderPathW(NULL, lpString, CSIDL_COMMON_PROGRAMS, FALSE); Rolf Kalbermatter

1 0

Re: Forwards exports - anyone?
by Rolf Kalbermatter 29 Oct '03

29 Oct '03

Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: >I'm trying to implement unicows.dll. The theory is quite simple - since >unicows merely implements unicode functions that exist, theoretically, >only in Wine, all I have to do is create forwards (i.e. - ExtTextOutW in >unicows.dll will call ExtTextOutW in GDI). This is slightly inefficient, >but should solve our unicows.dll problems. > >If I can merely instruct the dynamic loader to return the GDI >ExtTextOutW function when someone tries to link with the unicows >ExtTextOutW, I can solve the inefficiency in a clean, working way >without further problems. I thought this was done in Wine in the spec files. Something such as: @ stdcall ExtTextOutW(params) gdi32.ExtTextOutW should do the trick. The function names need not to be the same. The only limitation I have found is that you can't forward in this way to ordinal exports but I may have missed something. Rolf Kalbermatter

1 0

How do i find the start menu path?
by Robert van Herk 29 Oct '03

29 Oct '03

Hi people, I have a question for my start menu generator, that is almost finished now... How do I find the path of the wine start menu? (for me it's ~/c/windows/Start Menu, but for someone else it does not have to be like that...) Any help here? Grtz, Robert

2 1

Re: Serious Bug
by Boaz Harrosh 29 Oct '03

29 Oct '03

I'm Just exactly now fighting same problems. See my last post: "Help with shared library make files" Note 2 things A. Initialization order is opposite of msvc++ Last object on the linker gets to run first. (msvc first on the command line first to initialize) B. Hard, in gdb (kdevelop), to set a break point on pre-main code. use below file to do that. Put it as last object linked and after any library. In effect it is an "int 0x03" instruction to hard code a break point. C. All DLLs linked to the MyApp.dll.so should also link to MyApp.exe.so see my wine post: "wine msvcrt on Library initialization". These are the ones that get linked through winebuild. <Cpp_Globs_stop.cpp> #include "windows.h" #define _CrtDbgBreak() __asm__ ("\tint $0x3\n") class TestStaticClass { public: TestStaticClass() ; ~TestStaticClass() ; } ; TestStaticClass::TestStaticClass() { MessageBox(NULL ,"Constructor" ,"Cpp_Globs_stop" ,MB_OK) ; _CrtDbgBreak(); } TestStaticClass::~TestStaticClass() { MessageBox(NULL ,"Destructor" ,"Cpp_Globs_stop" ,MB_OK) ; } TestStaticClass g_StaticClass ; </Cpp_Globs_stop.cpp> <Makefile snippet> $(mfctest_dll_MODULE).so: $(mfctest_dll_MODULE).spec.o $(mfctest_dll_OBJS) Cpp_Globs_stop.o $(LDXXSHARED) $(LDDLLFLAGS) -o $@ \ $(mfctest_dll_MODULE).spec.o \ $(mfctest_dll_OBJS) \ $(mfctest_dll_LIBRARY_PATH) \ $(mfctest_dll_LIBRARIES:%=-l%) \ $(ALL_LIBRARIES) \ Cpp_Globs_stop.o \ </Makefile snippet> Now you can single step the initialization chain. flyker wrote: > Boaz Harrosh wrote: > >> use --wrap in winemaker. Read about this option in the documentation >> > Thanks. It is work :) > > > >

1 0

Re: Serious Bug
by flyker 29 Oct '03

29 Oct '03

Boaz Harrosh wrote: > use --wrap in winemaker. Read about this option in the documentation > Thanks. It is work :)

1 0

Serious Bug
by flyker 29 Oct '03

29 Oct '03

The simple test crashes wine. And i think many other commands in constructor A() may crash wine. test.cpp: #include <windows.h> #include <stdio.h> class A { public: A(); }; A::A() { LoadLibrary("user32.dll"); // all ok user32.dll is present } A a; int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR szCmdLine, int nCmdShow) { return 0; }

2 2

Help with shared library make files
by Boaz Harrosh 29 Oct '03

29 Oct '03

I have the following setup mfctest/Makefile - Main make file mfctest.exe.so - is the wrapper for an mfc gui application mfctest.dll.so - is the mfc gui application (as generated by the msvc++ wizard and than winemaker) msvc/Makefile - make file for mfc & stuff missing from msvcrt.dll libmsvc.a - is all the cpp files archived by [ ar -rs $(ALL_OBJECT_FILES) ] libmsvc.so - same object files but linked with [ gcc --shared ] Now I link mfctest.dll.so with libmsvc.a. (-l) The spec.c I prepare by including all the object files of the msvc project since winebuild does not work with libraries. It all runs fine. Now I try to link with libmsvc.so ( exact same way as before with the -l option linux style, not as a DLL as usually done in wine ). At the beginning it would not link because of undefined symbols. ( before with the .a option not all files get pulled in by the linker). So I fix the undefined s. The spec.c file I have tried in to ways. 1) a libmsvc.spec.c for libmsvc.so and a small one for mfctest.dll.spec.c - and 2) A big mfctest.dll.spec.c that includes all objects same as above libmsvc.a . In both cases I had the same exact problem. It would not run. I get a SIGSEGV. On the (gdb) back-trace it is directly from "dlopen" (from BUILTIN32_dlopen) it SIGs 10 functions deep into dlopen. The last function that makes any sense is _dl_init in ld-linux.so.2 from than on I get un-logical symbols that should not be in the init path. Including undefined s like 0x00000094 (see complete back-trace below) the SIGSEGV itself is reported at "dllname" which is not a function but an array in dll.spec.c . So we can see that the debug info got totally screwed up. Big help!!! Any body got any ideas? Do you think I need to fix the start address of libmsvc.so some how? What is the command line option for that? The reason I need the libYYY.so option to work is because I have a big (1900 files) C++ project divided into 36 libraries. On the windows side it is dlls & static libs, all automatically exported by msvc++ (#define class class declspec(dllexport) ). Since we do not have a good C++ way for pure dlls in wine (yet) and the 1900 files on one gcc link will not work. ( truncated by the linker) .And I have more Applications in the future that use the same libraries. The .so option looks best. One more question: What do the gurus say? In theory, if I have a XXX.dll.so linked Linux style to libYYY.so both have calls into wine. what is best method (XXX.dll.so is only because of the wrapper no real exports here) A. XXX.dll.so has an XXX.spec.c && libYYY.so has a YYY.spec.c of its own each linked to their respective .spec.c . (Note that those are only imports since export symbols from libYYY.so are linked against - Linux style). B. one big XXX+YYY.spec.c linked against XXX.dll.so (very very slow, it looks like winebuild has an o(n^2) efficiency ) C. Both are good if no exports are made. (or exports only at the top lib) Thanks for any help or pointer. Please share past experience for good or for worse Free Life Boaz some info: <(gdb) backtrace> #0 0x40cb3a4d in dllname () from /home/wine/lib/wine/mfctest.dll.so #1 0x00000094 in ?? () #2 0x40ffec8e in std::basic_iostream<wchar_t, std::char_traits<wchar_t> >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #3 0x40ffed0a in std::basic_iostream<wchar_t, std::char_traits<wchar_t> >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #4 0x4104dbb7 in __cxa_dyn_string_eq () from /usr/lib/libstdc++.so.5 #5 0x40feea11 in std::collate<char>::id () from /usr/lib/libstdc++.so.5 #6 0x4000aa4c in _dl_init (main_map=0x3c02eaf0, argc=4, argv=0xbffff454, env=0xbffff468) at dl-init.c:68 #7 0x4030a51e in _dl_open () from /lib/i686/libc.so.6 #8 0x4000a828 in _dl_catch_error (objname=0x406d28e0, errstring=0x406d28e4, operate=0x4030a120 <_dl_open+432>, args=0x406d28e8) at dl-error.c:162 #9 0x40309fcf in _dl_open () from /lib/i686/libc.so.6 #10 0x40352f21 in dlopen () from /lib/libdl.so.2 #11 0x4000a828 in _dl_catch_error (objname=0x3c0017e0, errstring=0x3c0017e4, operate=0x40352ef0 <dlopen+80>, args=0x406d2a68) at dl-error.c:162 #12 0x40353294 in dlerror () from /lib/libdl.so.2 #13 0x40352ed3 in dlopen () from /lib/libdl.so.2 #14 0x40107abc in wine_dlopen (filename=0x3c02eaa0 "/home/wine/lib/wine/mfctest.dll.so", flag=2, error=0x406d2b08 " ¨<@´l\016@X,m@HÍ\a@", errorsize=256) at loader.c:577 #15 0x40107420 in dlopen_dll (name=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@´l\016@X,m@HÍ\a@", errorsize=256, test_only=0) at loader.c:156 #16 0x4010795b in wine_dll_load (filename=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@´l\016@X,m@HÍ\a@", errorsize=256) at loader.c:390 #17 0x4009b537 in BUILTIN32_dlopen (name=0x406d2c2c "mfctest.dll", handle=0x406d2c28) at ../../relay32/builtin32.c:63 #18 0x4009b94c in BUILTIN32_LoadLibraryExA (path=0x403ca710 "C:\\WINDOWS\\SYSTEM\\mfctest.dll", flags=0, pwm=0x406d2cc4) at ../../relay32/builtin32.c:171 #19 0x400b3c6d in load_dll (libname=0x403ca6f0 "mfctest.dll", flags=0, pwm=0x406d2cc4) at loader.c:1058 #20 0x400b3e34 in LdrLoadDll (path_name=0x0, flags=0, libname=0x406d2cfc, hModule=0x406d2cf8) at loader.c:1120 #21 0x4007e158 in LoadLibraryExA (libname=0x404b41a0 "mfctest.dll", hfile=0x0, flags=0) at ../../loader/module.c:655 #22 0x4007e28d in LoadLibraryA (libname=0x404b41a0 "mfctest.dll") at ../../loader/module.c:707 #23 0x404a3147 in WinMain (hInstance=0x404b0000, hPrevInstance=0x0, szCmdLine=0x403908f2 "", iCmdShow=1) at mfctest.exe_wrapper.c:127 #24 0x404b40ea in __wine_exe_main () at mfctest.exe.spec.c:140 #25 0x4009fced in start_process () at ../../scheduler/process.c:455 #26 0x400a402a in call_on_thread_stack (func=0x4009fb10) at ../../scheduler/sysdeps.c:113 </(gdb) backtrace> <(gdb) info sharedlibrary> >From To Syms Read Shared Object Library 0x40048000 0x400c6314 Yes /home/wine/lib/libntdll.dll.so 0x40105790 0x40107c14 Yes /home/wine/lib/libwine.so.1 0x4011cc80 0x4011f354 Yes /home/wine/lib/libwine_unicode.so.1 0x40212620 0x4030f328 Yes /lib/i686/libc.so.6 0x403334a0 0x4034abc4 Yes /lib/i686/libm.so.6 0x40352db0 0x40353d64 Yes /lib/libdl.so.2 0x40000a60 0x4000f49b Yes /lib/ld-linux.so.2 0x40382d10 0x4038b054 Yes /lib/libnss_files.so.2 0x404a3000 0x404b4184 Yes /home/wine/codeward/mfctest/mfctest.exe.so 0x406f3000 0x40732ef4 Yes /home/wine/lib/wine/kernel32.dll.so 0x407b6000 0x40848b14 Yes /home/wine/lib/wine/user32.dll.so 0x408cf000 0x40916c44 Yes /home/wine/lib/wine/gdi32.dll.so 0x40941000 0x4095e814 Yes /home/wine/lib/wine/advapi32.dll.so 0x40974000 0x4099def4 Yes /home/wine/lib/wine/msvcrt.dll.so 0x409b1850 0x409ee254 Yes /usr/lib/libfreetype.so.6 0x409f98e0 0x40a02194 Yes /lib/libz.so.1 0x40a13000 0x40a5e794 Yes /home/wine/lib/wine/x11drv.dll.so 0x404b8200 0x404bc8a4 Yes /usr/X11R6/lib/libSM.so.6 0x40a73540 0x40a81dd4 Yes /usr/X11R6/lib/libICE.so.6 0x40a89910 0x40a934a4 Yes /usr/X11R6/lib/libXext.so.6 0x40aa6380 0x40b17384 Yes /usr/X11R6/lib/libX11.so.6 0x40b99640 0x40bd91e4 Yes /usr/X11R6/lib/libGL.so.1 0x40beb110 0x40bf3c14 Yes /lib/i686/libpthread.so.0 0x40c39320 0x40c3e234 Yes /usr/X11R6/lib/libXcursor.so.1 0x40c41390 0x40c46324 Yes /usr/X11R6/lib/libXrender.so.1 0x40014860 0x40015794 Yes /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 0x40c74260 0x40c8ad84 Yes /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 0x400185f0 0x40018f54 Yes /usr/lib/gconv/ISO8859-1.so 0x40ca0000 0x40cb2074 Yes /home/wine/lib/wine/mfctest.dll.so 0x40dcf920 0x40f2f8e4 Yes /home/wine/lib/libmsvc.so 0x40ff1070 0x4104dbc4 Yes /usr/lib/libstdc++.so.5 0x4001b540 0x40020534 Yes /lib/libgcc_s.so.1 </(gdb) info sharedlibrary>

1 0

Re: French keyboard layout with Euro symbol
by RemiAssailly＠aol.com 29 Oct '03

29 Oct '03

I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...

4 10

Re: DINPUT device unacquire (mouse) fix
by Andreas Mohr 29 Oct '03

29 Oct '03

Hi, On Tue, Oct 28, 2003 at 02:53:44AM +0200, Hannu Valtonen wrote: > License: LGPL > > I stumbled upon this when looking at fixing mouse support for Crimson > lands. According to MSDN DirectInputDevice Unacquire is allowed even for > devices which haven't been acquired yet. > > Changelog: > - SysMouseAImpl_Unacquire should return DI_NOEFFECT if the device is not > in an acquired state. Ah, thanks!! Maybe this is why some game (I believe it was UT) broke... Darn, why didn't I discover that when I stumbled on that place years ago? But don't you think keyboard and joystick might need the same code?? (keyboard has it as well, but with completely different code --> mess) This could probably be cleaned up. Andreas Mohr

2 2

WinE-Bug? InternetCrackUrl incorrectly sets dwUrlPathLength
by Jan Sporbeck 29 Oct '03

29 Oct '03

Hi, During some application testing, we discovered that WinE does not correctly mimic the WinINet function InternetCrackUrl. The real WinAPI sets the dwUrlPathLength member of the URL_COMPONENTS structure to additionally hold the extra info of the given URL if the extra info is not requested as a separate component. Although this behaviour is not well documented by the Win SDK, it is for instance implemented on WinXP, Win2000 and WinME and therefore might be considered to be intended by Microsoft. The following lines of code demonstrate the problem: LPCTSTR lpszURL = _T("http://www.myserver.com/myscript.php?arg=1"); URL_COMPONENTS url; // call 1: crack out url path and extra info ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; url.dwExtraInfoLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // dwUrlPathLength is 13, holding "/myscript.php" // call 2: only crack out url path ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // now, dwUrlPathLength should be 19, holding "/myscript.php?arg=1", // while WinE still sets it to 13 OK, it is of course no great deal to write code that correctly runs on real Win systems and on WinE (2-3 lines did it). But programers who rely on this behaviour will for example wonder why their applications don't transmit any HTTP GET parameters when they call HttpOpenRequest with lpszObjectName set to the URL path component returned by InternetCrackUrl... This applies to Wine 20031016, haven't found any recent report on this though. /jan.

1 0

spec files - syntax and generation
by "Martin Tröster" 29 Oct '03

29 Oct '03

Hi, once again I would like to get your advice on spec files. I now compiled a Windows application successful against winelib and can link it without problems. However, the application segfaults immediately when starting wine. I am tracking this back to .spec files (although I will need to debug in the next free time to be sure), since they are the weakest link I am seeing, since I wrote most of them by hand. So it would be great if you can answer the following questions: - Automatic generation: I composed the spec files by hand, based on Windows def files. Is there an automatic way to do that? I noticed a (somewhat hidden) tool called winedump, with nearly not existing documentation, but could not make much use of it. Any hints here? - Stack size and parameters in spec file: The def files are, as far as I know, very similar to the spec files: they contain the function name (either mangled or not mangled), as well as (most of the time) the stack space - format: functionname@stackspace. Is there anything wrong to translate an entry for "char* testfunc(char* str, int var1, long var2, long* ptr)" called "testfunc@16" into "@stdcall testfunc(ptr ptr ptr ptr)", without caring for the type of parameters? More explicitely asked, what use do I have from using str or long instead of ptr in the spec file? - Stdcall vs. cdecl How do I find out whether a function uses CDECL instead of STDCALL? I found the information (link lost unfortunately) that entries in the def file like testfunc1@0 are called via STDCALL, whereas in case of testfunc2 without any @ specifying the space is CDECL. Is this guess right? If not, how else do I find this out? Thanks again for any help! Cheers, Martin ______________________________________________________________________________ Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182

4 5

Re: PATCH: server/named_pipe.c (RESENT)
by Alexandre Julliard 28 Oct '03

28 Oct '03

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > was there any problem with the following patch, or did it just fall > through the cracks? ;-) > > Gerald > > ChangeLog: > Remove unused variable pipe_client_fd_ops. Well, either the client side should really use pipe_client_fd_ops, or pipe_server_fd_ops should be renamed to show that it is used by both client and server. I'm not sure which one was intended, could the named pipe experts please check that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Support for TLS in CrossOver
by Mike Hearn 28 Oct '03

28 Oct '03

Hi Alexandre, I noticed the ChangeLog for the new CXOffice release (congrats on that btw!) said it now works with all glibc 2.3 variants. Does that mean the TLS related named pipe breakage we saw earlier is now fixed? If so, do you know when the fix will be in WineHQ CVS? thanks -mike

3 3

WineHQ: PATCH to fix IPersistFile::Load() and associated functions
by Subhobroto Sinha 28 Oct '03

28 Oct '03

Hello all I finally produced the "official patch" after verifying that everything is OK. This patch has been inlined as well as attached as a ZIP file, so suit yourself. All reports regaring this patch is to be sent to <subhobrotosinha at yahoo.com> with a proper subject prefixed by "IPersistFile patch" in the subject header. Just don't simply hit the 'Reply' button ! This patch fixes: (1) Stream_LoadString: Conflict of unicode strings being taken as LPSTR and AGAIN being converted to Unicode due to wrong value of SCF_UNICODE .(I have really NOT changed the original code, but redirected this call to a fixed function which I named wineStream_LoadString. This should remain so until SCF_UNICODE value is corrected) (2) Stream_LoadLocation: Previously the GetPath() failed. It works great now. For the uninitiated, here's what has to be done: Please make sure that you have the 20031016 source (latest tarball) (1)Copy this .diff to the root folder of the Wine source (2)Run 'patch' on this diff file (3)It should patch "dlls/shell32/shelllink.c". Change to that directory (4)Type 'make' to rebuild 'shell32.dll.so' (5)'su' out and overwrite/symlink the current 'shell32.dll.so' over the installed one Now IPersistFile::Load() should work as intended. Try out McCormack's 'winemenubuilder' or my WineLib 'linkresolve' (NOT my C++ version) If the diff is not proper, etc, please alert me at the mentioned address PS: As I am not a member of 'wine-patches',can the moderator be kind enough... :=) I really want these functions to get fixed. That's all. Regards Subhobroto Sinha __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- dlls/shell32/shelllink.c.original 2003-10-22 17:56:31.000000000 +0530 +++ dlls/shell32/shelllink.c 2003-10-26 16:30:57.000000000 +0530 @@ -401,9 +401,49 @@ return S_OK; } +static HRESULT wineStream_LoadString( IStream* stm, LPWSTR *pstr ) +{ + DWORD count=0; + USHORT len; + LPWSTR str=NULL; + HRESULT r; + /* + From Win98 upwards unicode==TRUE.(Atleast for shortcuts..) + However, the value of SCF_UNICODE does NOT seem to be 0x1000. + Until then, we assume it true. + Anybody differing mail to <subhobrotosinha at yahoo.com>. + */ + TRACE("%p\n", stm); + + r = IStream_Read(stm, &len, sizeof(len), &count); + if(FAILED(r)||(count != sizeof(len))) return E_FAIL; + + len *= sizeof(WCHAR); + + TRACE("reading %d\n", len); + str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR)); + if(!str) return E_OUTOFMEMORY; + + count = 0; + r = IStream_Read(stm, str, len, &count); + if( FAILED(r)||( count!=len) ) + { + HeapFree( GetProcessHeap(), 0, str ); + return E_FAIL; + } + + str[count/2]=0; + *pstr = str; + TRACE("read %s\n", debugstr_w(str)); + return S_OK; +} static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr ) { +/*This is the original function short circuited to the above till we find out correct 'SCF_UNICODE'. +Now it's assumed that the data's unicode. (This assumption failes iff the OS was <=Win95*/ +return (wineStream_LoadString(stm,pstr)); +#if 0 DWORD count; USHORT len; LPVOID temp; @@ -453,6 +493,7 @@ *pstr = str; return S_OK; +#endif } static HRESULT Stream_LoadLocation( IStream* stm ) @@ -533,6 +574,14 @@ if( FAILED( r ) ) return r; } + ////////////////////////////////////////////////////////////////////////////////////// + char szTemp[MAX_PATH]={0}; + SHGetPathFromIDListA(This->pPidl,szTemp); + This->sPath=HeapAlloc( GetProcessHeap(), 0,(strlen(szTemp)+1)*sizeof(WCHAR)); + MultiByteToWideChar(CP_ACP,0,szTemp,(strlen(szTemp)+1),This->sPath,(strlen(szTemp)+1)); + //TRACE("%s\n",szTemp); + ////////////////////////////////////////////////////////////////////////////////////// + This->wHotKey = hdr.wHotKey; This->iIcoNdx = hdr.nIcon; FileTimeToSystemTime (&hdr.Time1, &This->time1);

3 3

Winesetuptk 0.7 released
by Ivan Leo Murray-Smith 28 Oct '03

28 Oct '03

Hi lists, Winesetuptk 0.7 is at the wine sourceforge page http://sourceforge.net/project/showfiles.php?group_id=6241 This new version contains an updated winedefault.reg, you don't need to run regedit winedefault.reg any more, and it's updated to configurate all the latest and greatest features of wine. This release was possible thanks to the help and contributions of Vincent Béron and Alex Pasadyn. Without them, winesetuptk 0.7 wouldn't exist. Download and enjoy!

1 0

Status of HeapAlloc Cleanup in shell32
by Steven Edwards 28 Oct '03

28 Oct '03

Is the HeapAlloc/ReAlloc stuff being tracked anywhere? I think it is the cause of a lot of problems I have with shell32 under Windows and ReactOS. Applications linked to wine shell32.dll under Windows2000 run fine but when you exit they get illigal op's where the memory could not be "read" kind of like the bug I had in uninstaller.exe that started the HeapAlloc cleanup. Thanks Steven __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel