wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: SNOOP: How to find out if an DLL entry is a DATA reference?
by Alexandre Julliard 14 Aug '01

14 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > However I like to ask if there are other methods of distinguishing DATA and > function references? Could the PE loader perhaps know? Or can we perhaps > protect our snoop entries from being read as data and catch those exceptions? > Any other idea? I don't think there's any way to make snoop 100% reliable, the PE file simply doesn't contain enough information. This is the reason we have to build special tables in the builtin dlls for relay debugging. -- Alexandre Julliard julliard(a)winehq.com

1 0

Advice please. adding a MODULE_LoadLibraryExA argument
by Bill Medland 14 Aug '01

14 Aug '01

I'd appreciate advice on this. I am looking at adding the handling of LoadLibraryExA (..LOAD_WITH_ALTERED_SEARCH_PATH) (which we use) and I am wondering about how to carry around the library directory during the recursion on MODULE_LoadLibraryExA. The easiest way is to put it in a static variable (ok, some allocated memory pointed to by a static variable) and depend upon the existing critical sections (which I don't understand particularly) to ensure it is only used by the currently loading tree of DLLS (i.e. set it up after the RtlAcquirePebLock in MODULE_LoadLibraryExA). However I dislike using static variables as a matter of principle. The way I would prefer would be to add an argument to all the functions in the recursion and use that to carry the name around. MODULE_LoadLibraryExA PE_LoadLibraryExA ELF_LoadLibraryExA PE_CreateModule fixup_imports Any objections? Bill

1 0

Solaris X86 mmap...
by Robert Lunnon 14 Aug '01

14 Aug '01

On Jan 10 2001 Ulrich Weigand submitted a patch to library/port.c to attempt to fix the linux mmap behaviour dependency for solaris systems. After that point I can't find any reference to this patch, it certainly hasn't made it into the CVS yet ? Does anyone know the outcome of this work, or am I the only Solaris X86 user out there :-)

1 0

SNOOP: How to find out if an DLL entry is a DATA reference?
by Uwe Bonnes 14 Aug '01

14 Aug '01

Hallo, e.g. with the MFC libraries the snoop option crashes quite often, while without snoop the programm proceeds some more. Digging deeper for the crash in msdev.exe, I saw that a library has exported DATA entries mixed into the codesegment. Our snoop loader only checks for DATA entries in the PE DATA section and so happyly overwrites data. It seems that most exported DATA entries have a decorated name ending in @A or @B and by handling entries with that ending as DATA, the crash with msdev.exe happens at the same place with or without snoop. Appended patch does this hacky search for DATA entries. However I like to ask if there are other methods of distinguishing DATA and function references? Could the PE loader perhaps know? Or can we perhaps protect our snoop entries from being read as data and catch those exceptions? Any other idea? Bye Changelog: relay32/snoop.c: SNOOP_GetProcAddress Don't snoop on names ending in "@A" and "@B", they seem to be DATA entries. Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/relay32/snoop.c =================================================================== RCS file: /home/wine/wine/relay32/snoop.c,v retrieving revision 1.45 diff -u -r1.45 snoop.c --- wine/relay32/snoop.c 24 Jul 2001 21:45:24 -0000 1.45 +++ wine/relay32/snoop.c 13 Aug 2001 19:51:42 -0000 @@ -158,7 +158,7 @@ SNOOP_GetProcAddress(HMODULE hmod,LPCSTR name,DWORD ordinal,FARPROC origfun) { SNOOP_DLL *dll = firstdll; SNOOP_FUN *fun; - int j; + int j,len; IMAGE_SECTION_HEADER *pe_seg = PE_SECTIONS(hmod); if (!TRACE_ON(snoop)) return origfun; @@ -182,7 +182,14 @@ !(pe_seg[j].Characteristics & IMAGE_SCN_CNT_CODE) ) return origfun; - + /* some heuristic to filter out DATA objects + decorated names end like "@A" and "@B" and some more */ + len=strlen(name); + if ((name [len-2] == '@') && ((name[len-1] == 'A') || (name[len-1] == 'B'))) + { + return origfun; + } + while (dll) { if (hmod == dll->hmod) break;

2 1

IShellLinkA_fnSetIconLocation problem with Kid Pix 3?
by Dan Kegel 13 Aug '01

13 Aug '01

Kid Pix 3 doesn't install with Wine from cvs (with either August 6th's or today's cvs). The problem appears to be related to shortcut or icon creation, as the installer bombs with alert "Cannot create shortcuts." right after checking for the existence of "Picker.ico". Here is what seems to be the interesting 250-line section of the log, starting with the fnSetIconLocation and ending with the "Cannot create shortcuts". There is an iffy looking line near the bottom I've marked with !!!!!!!!!!!!!. I'd be grateful for any suggestions. Thanks, Dan trace:shell:IShellLinkA_fnSetIconLocation (0x418884bc)->(path=C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico iicon=0) trace:shell:IShellLinkA_fnQueryInterface (0x418884bc)->( IID: {0000010b-0000-0000-c000-000000000046}) trace:shell:IPersistFile_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnAddRef (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnQueryInterface -- Interface: (0x405d53fc)->(0x418884c8) 08077c28:Call kernel32.MultiByteToWideChar(00000000,00000000,405d51dc "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4dc0,00000104) ret=100394e7 08077c28:Ret kernel32.MultiByteToWideChar() retval=00000034 ret=100394e7 trace:shell:IPersistFile_fnSave (0x418884bc)->(L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk") 08077c28:Call advapi32.RegOpenKeyExA(80000002,40879140 "Software\\Wine\\Wine\\Config\\Wine",00000000,000f003f,405d490c) ret=408563c4 08077c28:Call ntdll.RtlInitAnsiString(405d47dc,40879140 "Software\\Wine\\Wine\\Config\\Wine") ret=407afaa4 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407afaa4 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d47dc,00000000) ret=407afaad 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407afaad 08077c28:Call ntdll.NtOpenKey(405d490c,000f003f,405d47e4) ret=407afac0 trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\Wine",f003f,0x405d490c) trace:reg:NtOpenKey <- 0x0034 08077c28:Ret ntdll.NtOpenKey() retval=00000000 ret=407afac0 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407afac6 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407afac6 08077c28:Ret advapi32.RegOpenKeyExA() retval=00000000 ret=408563c4 08077c28:Call advapi32.RegQueryValueExA(00000034,4087915f "ShellLinker",00000000,405d4904,405d4c90,405d4908) ret=408563fb trace:reg:RegQueryValueExA (0x34,"ShellLinker",(nil),0x405d4904,0x405d4c90,0x405d4908=260) 08077c28:Call ntdll.RtlInitAnsiString(405d46f4,4087915f "ShellLinker") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d46f4,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d46fc,00000100,405d46f0) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"ShellLinker",2,0x405d46fc,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4708 L"wineshelllink",0000000e,405d4c90,0000000e,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=0000000e ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=408563fb 08077c28:Call advapi32.RegCloseKey(00000034) ret=40856411 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=40856411 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4dc0 L"C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",ffffffff,405d4c90,00000104,00000000,00000000) ret=40856482 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000034 ret=40856482 08077c28:Call kernel32.GetFullPathNameA(405d4c90 "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk",00000104,405d4b80,00000000) ret=408564b0 trace:string:lstrcpynA (0x405d43dc, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 1024) trace:string:lstrcpynA (0x405d4b80, "C:\\Windows\\Desktop\\Shortcut to Kid Pix Deluxe 3.lnk", 260) 08077c28:Ret kernel32.GetFullPathNameA() retval=00000033 ret=408564b0 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=7,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "StartUp",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"StartUp",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "StartUp") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"StartUp",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Start Menu\\Programs\\Startup",00000027,405d4c90,00000027,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000027 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Start Menu\Programs\Startup 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Start Menu\\Programs\\Startup") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 trace:shell:SHGetSpecialFolderPathA 0x0000,0x405d4c90,csidl=16,0x0000 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d37e 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bb20 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d37e 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d3aa trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=c0000034 ret=407b0cc4 08077c28:Call ntdll.RtlNtStatusToDosError(c0000034) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000002 ret=4085d3aa 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d3bd 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d3bd 08077c28:Call advapi32.RegCreateKeyExA(80000001,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",00000000,00000000,00000000,000f003f,00000000,405d4568,405d456c) ret=4085d3e8 08077c28:Call ntdll.RtlInitAnsiString(405d443c,4087bac0 "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders") ret=407af91e 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407af91e 08077c28:Call ntdll.RtlInitAnsiString(405d4434,00000000) ret=407af92d 08077c28:Ret ntdll.RtlInitAnsiString() retval=400bf8ac ret=407af92d 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d443c,00000000) ret=407af936 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af936 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(405d442c,405d4434,00000001) ret=407af94a 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407af94a 08077c28:Call ntdll.NtCreateKey(405d4568,000f003f,405d4444,00000000,405d442c,00000000,405d456c) ret=407af968 trace:reg:NtCreateKey (0x80000001,L"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders",L"",0,f003f,0x405d4568) trace:reg:NtCreateKey <- 0x0034 08077c28:Ret ntdll.NtCreateKey() retval=00000000 ret=407af968 08077c28:Call ntdll.RtlFreeUnicodeString(405d442c) ret=407af970 08077c28:Ret ntdll.RtlFreeUnicodeString() retval=00000001 ret=407af970 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407af976 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407af976 08077c28:Ret advapi32.RegCreateKeyExA() retval=00000000 ret=4085d3e8 08077c28:Call advapi32.RegQueryValueExA(00000034,405d4790 "Desktop",00000000,405d4560,405d4c90,405d4564) ret=4085d408 trace:reg:RegQueryValueExA (0x34,"Desktop",(nil),0x405d4560,0x405d4c90,0x405d4564=260) 08077c28:Call ntdll.RtlInitAnsiString(405d4374,405d4790 "Desktop") ret=407b0c79 08077c28:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=407b0c79 08077c28:Call ntdll.RtlAnsiStringToUnicodeString(4010bbf8,405d4374,00000000) ret=407b0c8e 08077c28:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=407b0c8e 08077c28:Call ntdll.NtQueryValueKey(00000034,4010bbf8,00000002,405d437c,00000100,405d4370) ret=407b0cc4 trace:reg:NtQueryValueKey (0x34,L"Desktop",2,0x405d437c,256) 08077c28:Ret ntdll.NtQueryValueKey() retval=00000000 ret=407b0cc4 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,00000000,00000000,00000000,00000000) ret=407b0ddc 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0ddc 08077c28:Call kernel32.WideCharToMultiByte(00000000,00000000,405d4388 L"C:\\WINDOWS\\Desktop",00000013,405d4c90,00000013,00000000,00000000) ret=407b0e1b 08077c28:Ret kernel32.WideCharToMultiByte() retval=00000013 ret=407b0e1b 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b0ed2 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b0ed2 08077c28:Ret advapi32.RegQueryValueExA() retval=00000000 ret=4085d408 08077c28:Call advapi32.RegCloseKey(00000034) ret=4085d579 08077c28:Call ntdll.NtClose(00000034) ret=407b04e2 08077c28:Ret ntdll.NtClose() retval=00000000 ret=407b04e2 08077c28:Call ntdll.RtlNtStatusToDosError(00000000) ret=407b04e8 08077c28:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=407b04e8 08077c28:Ret advapi32.RegCloseKey() retval=00000000 ret=4085d579 08077c28:Call shlwapi.PathFileExistsA(405d4c90 "C:\\WINDOWS\\Desktop") ret=4085d7d6 trace:shell:PathFileExistsA C:\WINDOWS\Desktop 08077c28:Call kernel32.GetFileAttributesA(405d4c90 "C:\\WINDOWS\\Desktop") ret=408fd447 trace:string:lstrcpynA (0x405d3bfc, "/home/dank/.wine/fake_windows", 1024) 08077c28:Ret kernel32.GetFileAttributesA() retval=00000010 ret=408fd447 08077c28:Ret shlwapi.PathFileExistsA() retval=00000001 ret=4085d7d6 08077c28:Call kernel32.wine_get_unix_file_name(4187b708 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\KPRUN.EXE",405d4a70,00000104) ret=4085669d trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4a70, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085669d 08077c28:Call kernel32.wine_get_unix_file_name(41888530 "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3",405d4960,00000104) ret=4085671c trace:string:lstrcpynA (0x405d4004, "/home/dank/.wine/fake_windows", 1024) trace:string:lstrcpynA (0x405d4960, "/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3", 260) 08077c28:Ret kernel32.wine_get_unix_file_name() retval=00000001 ret=4085671c 08077c28:Call kernel32.LoadLibraryExA(4188856c "C:\\Program Files\\Broderbund\\Kid Pix Deluxe 3\\Picker.ico",00000000,00000002) ret=40855d46 trace:string:lstrcpynA (0x405d3e70, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x405d3e2c, "/home/dank/.wine/fake_windows", 1024) warn:dosfs:DOSFS_FindUnixName 'Picker.ico' not found in '/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' trace:string:lstrcpynA (0x418886ec, "C:\\WINDOWS\\SYSTEM", 260) !!!!!!!!!!!!!!!!!!!! why is it trying to load C:\WINDOWS\SYSTEM?! !!!!!!!!!!!!!!!!! warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM'; error=0x00000002, 08077c28:Ret kernel32.LoadLibraryExA() retval=00000000 ret=40855d46 trace:shell:ExtractFromEXEDLL LoadLibraryExA (C:\Program Files\Broderbund\Kid Pix Deluxe 3\Picker.ico) failed, error 2 trace:shell:IPersistFile_fnSave linker app='wineshelllink' link='Shortcut to Kid Pix Deluxe 3' mode=desktop path='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3/KPRUN.EXE' args=' Main' icon='/tmp/fileUlFDEJ' workdir='/home/dank/.wine/fake_windows/Program Files/Broderbund/Kid Pix Deluxe 3' descr='' fixme:pthread_kill_other_threads_np trace:shell:IPersistFile_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=2) trace:shell:IShellLinkA_fnRelease (0x418884bc)->(count=1) trace:shell:IShellLinkA_fnRelease -- destroying IShellLink(0x418884bc) 08077c28:Call ole32.CoUninitialize() ret=10039541 08077c28:Call kernel32.FreeLibrary(40845000) ret=408b00fc 08077c28:Ret kernel32.FreeLibrary() retval=00000001 ret=408b00fc 08077c28:Ret ole32.CoUninitialize() retval=00000000 ret=10039541 08077c28:Call window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) 08077c28:Ret window proc 0x416979 (hwnd=000001c0,msg=WM_USER+000c,wp=00000000,lp=00000000) retval=00000000 08077c28:Call kernel32.lstrlenA(0048636c "") ret=00417ef4 08077c28:Ret kernel32.lstrlenA() retval=00000000 ret=00417ef4 08077c28:Call kernel32.lstrcpyA(4185a0e7,0048636c "") ret=0041801e 08077c28:Ret kernel32.lstrcpyA() retval=4185a0e7 ret=0041801e 08077c28:Call kernel32.lstrcpyA(405d6144,40491e32 "MESSAGE_CANNOT_CREATE_ICONS") ret=0041832a 08077c28:Ret kernel32.lstrcpyA() retval=405d6144 ret=0041832a 08077c28:Call kernel32.lstrlenA(4043bcec "Cannot create shortcuts.") ret=0045714a -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

Re: Question about network stuff
by Bobby Bingham 12 Aug '01

12 Aug '01

I'm not sure of the answer to your problem (could you be a little more specific than "it basically told me it couldn't access the network.) This isn't the right list for this question. This list is for patches that have been submitted to WINE. You might try the wine-users mailing list, or, if you're really daring, the wine-devel list if no one on wine-users knows Bobby Bingham Microsoft Windows: Made for the internet The Internet: Made for UNIX On Sunday 12 August 2001 02:02 am, you wrote: > Hi there > > (am I even on the right list??) > > I've been trying to get some Internet playable games to work with Wine, > namely everquest. > > I started out by making the mistake of running wine from my home dir (like > wine /win/d/everquest/everquest.exe) and having it download the whole game > from the 'net to my home dir.. I stopped that in a hurry :-) > > When I moved to /win/d/everquest, and tried to do wine ./everquest, it > basically told me it couldn't access the network. > > Why? How do I fix this? > > Thanks a ton, > > Tim

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 11 Aug '01

11 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > So to the details of the marshalling API (the unmarshalling API can wait). > 1. Where should we put them? Suggestion: include/wine/messsage.h No, it should be private to the dlls that really need it. We shouldn't add a global Wine-specific interface, we already have too many of that. And please don't go around converting all SendMessage calls to some marshalling API; this should be reserved to the cases where there is really a need. This is why I suggested to add the inline function in the C file directly: if there is a file where there are a lot of WM_COMMANDs with ugly casts, you can add an inline function there. But if there is only one or two, or calls that don't need ugly typecasts (most of them don't), then you definitely don't want to use the inline, just do a normal SendMessage. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 11 Aug '01

11 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We can just do it like: > > #ifdef __GNUC__ > > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, > HWND hwndCtl, UINT > > codeNotify, WNDPROC fn) > > { > > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > > } > > #else > > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > > (void)(fn)((hwnd), WM_COMMAND, > > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > > #endif > > > > if you wish. And if you are worried about preprocessor abusing > > Winelib application we could do #if defined(__GNUC__) && > defined(__WINE__) > > instead or use some kind of macro wrap around protection of the > > kind that I proposed that you didn't like. > > If you want to wrap WM_COMMAND, do something like: > > inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, > UINT codeNotify) > { > SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), > (LPARAM)hwndCtl); > } > > This is a normal function, doing a normal SendMessage call, and it's > perfectly all right with me. And if you want to do a PostMessage then > write a separate post_wm_command() function. Of course this is not a > standard Windows API so you cannot put it in the standard header > files; but you can have it in some dll private headers, or even > directly in the C files that need it. Ironically that was approximately my original idea. But I didn't think you would accept it so I didn't bother investigating further. Then I realized that the windowsx.h macros did what I wanted so choosed that solution instead. But sure we have a marshalling/unmarshalling API of our own, if that is what you want. Unless of course you prefer the hack below for PostMessage (not likely :-). So to the details of the marshalling API (the unmarshalling API can wait). 1. Where should we put them? Suggestion: include/wine/messsage.h 2. What should we call them? Suggestion: {POST,SEND}_WM_COMMAND etc. We really should capitalize the message name because of people doing "grep WM_COMMAND". And not capitalizing the POST/SEND would look silly if the suffix is capitalized. Sure they look like macros but then they could easily be made to be as an alterative implemention like #define SEND_WM_COMMAND(hwnd, id, hwndCtl, codeNotify) \ FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, SendMessage) 3. Do you want the macro wrapper (against the FORWARD API) above for the non GNU C case? 4. Should have have {POST,SEND}_WM_COMMAND{A,W} for calling {Post,Send}Message{A,W} or should we always the W variant like in your example above. > > To sum it up: > > 1. The FORWARD_* API and the HANDLE_* API really are normal > functions not > > macros (preprocessor abuses). The fact Micrsoft > implemented them as macros > > because of lack of compiler support for inline functions > or because of > > incompetence is irrelevant, we can do it right in a 100% > compatible way. > > No we can't; SendMessage and PostMessage don't have the same > prototype, so the preprocessor abuse is necessary to avoid > warnings. It seems you are right. PostMessage returns BOOL. Anyway there are not so many PostMessage calls that can be converted. $ find . -name \*.c | xargs grep PostMessage | grep WM_ | wc -l 35 The type compatible ones on the other hand are $ find . -name \*.c | xargs egrep 'Def.*Proc' | grep WM_ | wc -l 33 $ find . -name \*.c | xargs grep SendMessage | grep WM_ | wc -l 420 The Def.*Proc ones doesn't seem of closer examination to require marshalling of parameters so let skip them. Total 420 compared to 35. So we either decide not to use the the FORWARD_ API for such cases or we do: BOOL bResult = (BOOL) FORWARD_WM_COMMAND(/* ... */, (WNDPROC) PostMessageW); The use above is type correct regardless of whether FORWARD_WM_COMMAND is a macro or a inline function. A little ugly yes, but then it isn't nessary to convert the few PostMessage that exists to the FORWARD_* API at all.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 11 Aug '01

11 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > We can just do it like: > #ifdef __GNUC__ > extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT > codeNotify, WNDPROC fn) > { > fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); > } > #else > #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ > (void)(fn)((hwnd), WM_COMMAND, > MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) > #endif > > if you wish. And if you are worried about preprocessor abusing > Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) > instead or use some kind of macro wrap around protection of the > kind that I proposed that you didn't like. If you want to wrap WM_COMMAND, do something like: inline void send_wm_command(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify) { SendMessageW(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM)hwndCtl); } This is a normal function, doing a normal SendMessage call, and it's perfectly all right with me. And if you want to do a PostMessage then write a separate post_wm_command() function. Of course this is not a standard Windows API so you cannot put it in the standard header files; but you can have it in some dll private headers, or even directly in the C files that need it. > To sum it up: > 1. The FORWARD_* API and the HANDLE_* API really are normal functions not > macros (preprocessor abuses). The fact Micrsoft implemented them as macros > because of lack of compiler support for inline functions or because of > incompetence is irrelevant, we can do it right in a 100% compatible way. No we can't; SendMessage and PostMessage don't have the same prototype, so the preprocessor abuse is necessary to avoid warnings. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 11 Aug '01

11 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Microsoft introduced the windowsx.h macros for a reason and > > while without inline functions the current implementation > > of the FORWARD_* macros was the best they could do, it > > was at least better than nothing since it at least handled > > the parameter marshalling even if it wasn't 100% type safe. > > I wouldn't rely on Microsoft choices to judge an API design ;-) Point taken. :-) However not everything Microsoft does is bad, eventhough I admit that being sceptical is a good start. > > Another things to think about: > > What is the difference between calling {Set,Get}WindowText > > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? > > It's a matter of taste. Calling a normal function is perfectly all > right; But they are normal functions. It is just not that apparent that they really are. Whether this is by design or by accident I leave unsaid. :-) Anyway, see below. > but I find that using a macro (or worse an inline function > masquerading as a macro) and having to pass it the name of the > function you want to call is ugly and offensive. If you want to call > SendMessage, then call SendMessage, don't hide it inside a macro. It is not hidden in the macro. Which function to call is provided as the last parameter of the macro. > Just because you can do all kinds of abuses of the preprocessor in C > doesn't mean you should. Well actually, the so called abuses of the preprocesor was for 100% compabillity with Winelib applications, if they abuse the fact that FORWARD_* might not always be macros (like doing undef on them). It is possible do it cleaner that the crude example I provide as well. Anyway, with the exception of preprocessor abusing application, which Wine easily can be made not to be. We can just do it like: #ifdef __GNUC__ extern inline void FORWARD_WM_COMMAND(HWND hwnd, int id, HWND hwndCtl, UINT codeNotify, WNDPROC fn) { fn(hwnd, WM_COMMAND, MAKEWPARAM(id, codeNotify), (LPARAM) hwnd); } #else #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn) \ (void)(fn)((hwnd), WM_COMMAND, MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl)) #endif if you wish. And if you are worried about preprocessor abusing Winelib application we could do #if defined(__GNUC__) && defined(__WINE__) instead or use some kind of macro wrap around protection of the kind that I proposed that you didn't like. Note that the above inline function "abuses" that fact that C autocasts between functions and pointer to functions, but then it standard well documented and often used "abuse", so calling it an abuse isn't really fair (not that you did since my example contained an unnessary &)). To sum it up: 1. The FORWARD_* API and the HANDLE_* API really are normal functions not macros (preprocessor abuses). The fact Micrsoft implemented them as macros because of lack of compiler support for inline functions or because of incompetence is irrelevant, we can do it right in a 100% compatible way. 2. The FORWARD_* API provides marshalling of parameters and the HANDLE_* API provides unmarshalling of parameters. 3. The FORWARD_* API provides type safe sending of parameters and the HANDLE_* API provides type safe recieving of parameters. Note that the fact that marshalling and unmarshalling of parameters are hidden makes that code much more readable and yes, I say it again, the FORWARD_* API and HANDLE_* API really are normal functions, there is no hidden traps for the unwary user. Just a nice wrapper for type safe marshalling and unmarshalling of parameters. PS. We could easily rewrite the HANDLE_* API as inline functions as well, I don't think it gives us anything though. They are good as they are AFAICS. But if you don't like macros, sure I can rewrite them as inline functions well. It just a lot of work to no gain AFAICS. It wouldn't hurt either though.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 10 Aug '01

10 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > Microsoft introduced the windowsx.h macros for a reason and > while without inline functions the current implementation > of the FORWARD_* macros was the best they could do, it > was at least better than nothing since it at least handled > the parameter marshalling even if it wasn't 100% type safe. I wouldn't rely on Microsoft choices to judge an API design ;-) > Another things to think about: > What is the difference between calling {Set,Get}WindowText > functions and calling the FORWARD_WM_{GET,SET}TEXT macros? It's a matter of taste. Calling a normal function is perfectly all right; but I find that using a macro (or worse an inline function masquerading as a macro) and having to pass it the name of the function you want to call is ugly and offensive. If you want to call SendMessage, then call SendMessage, don't hide it inside a macro. Just because you can do all kinds of abuses of the preprocessor in C doesn't mean you should. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 10 Aug '01

10 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will give us all the advantages of the "macros" > without any typecasts > > that could > > possibly hide a type error. > > > > What do you say? > > I don't like it. I think windowsx.h should not be used at all in Wine; > it only obfuscates things by making it harder to see what's really > going on. Obfuscates what? The only thing the "macros" do is that it hides the way the parameters are marshalled. That is totally unintresting for almost all Wine developers. Like the Win16/Win32 thunking code you don't have to know how it works, you just call the appropriate functions. The same with the stdcall calling convention most API functions use. You add WINAPI before the function and you don't care how it works. It is the somebody else problem and you trust that they know what they are doing. So please explain what the use of FORWARD_* macros obfuscates for I really can't see it. AFAICS it is much better to use the FORWARD_ macros (especially with my hack to make them truely type safe). They are just a function like any other. Why look up how the parameters are marshalled when you can call a function FORWARD_* that not only does it, but does it in a type safe way. If you call the function with the wrong parameters you are very likely to get type errors. If you marshall the parameters in the wrong way it is almost 100% certain that the compiler will say nothing. Microsoft introduced the windowsx.h macros for a reason and while without inline functions the current implementation of the FORWARD_* macros was the best they could do, it was at least better than nothing since it at least handled the parameter marshalling even if it wasn't 100% type safe. Another things to think about: What is the difference between calling {Set,Get}WindowText functions and calling the FORWARD_WM_{GET,SET}TEXT macros? Answer: No difference at all except that you can easily do a PostMessage instead of a SendMessage if you wish. Of course I'm not suggesting that we should call the FORWARD_WM_{GET,SET}TEXT instead of {Set,Get}WindowText, but in most cases no appropriate functions exists and FORWARD_* macros will at least do the marshalling of parameters and if we implement my version of them also type safe. > Besides, the FORWARD_* macros are not really meant to be > used to send messages, they are meant to help receiving messages, so I > don't think we should abuse them that way. No, that is what the HANDLE_* macros are for. The FORWARD_* macros are for sending (or forwarding) messages. Speaking of which the HANDLE_* macros could find uses in COMCTL32 and other similar DLL:s to provide a type safe receiving of messages. I don't even think we will have to do as a proposed for the FORWARD_* to make them truely type safe.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Alexandre Julliard 10 Aug '01

10 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > This will give us all the advantages of the "macros" without any typecasts > that could > possibly hide a type error. > > What do you say? I don't like it. I think windowsx.h should not be used at all in Wine; it only obfuscates things by making it harder to see what's really going on. Besides, the FORWARD_* macros are not really meant to be used to send messages, they are meant to help receiving messages, so I don't think we should abuse them that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: RFC: Should we use the macros in windowsx.h to fix -DSTRICT w arni ngs?
by Patrik Stridvall 10 Aug '01

10 Aug '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So the question is: > > Should we use the FORWARD_WM_* macros to avoid typecasts > > (or rather avoid visable typecast) or should we not? > > If not how should we fix the problems? > > I think it's better to avoid that. Hiding the typecasts in the macros > doesn't really make things cleaner IMO. This is a case where the API > design forces us to use a typecast, so we might as well make it > explicit. True, but be aware of the macros often use a double type cast like (LPARAM)(HWND). I'm not sure this is really helpful, since I guess it will reveal but a few type error if any at all. Also note that the macros also takes care of MAKEWPARAM and MAKELPARAM stuff so it makes the code a little more readable. Anyway, never mind. We could be a little more clever than the macros permit that if we like. See below. > Note that for the specific case of WM_GET/SETTEXT, it would be much > better to use Get/SetWindowText which will do correct type checks. True. They was just an example. They are a few more with similar problems but they are few (less than 10 IIRC). I guess we can worry about them later. > But > for messages that don't have a corresponding function we have to do > the typecast. As the macros work now, yes. But we could extend the "macros" to be a little more clever than that. Take for example one of the more advanced macros #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) We could quite easily write it like: #define _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ (void)(fn)((hwnd), (fDoubleClick) ? WM_LBUTTONDBLCLK : WM_LBUTTONDOWN, (WPARAM)(UINT)(keyFlags), MAKELPARAM((x), (y))) #if defined(__WINE__) && defined(__GNUC__) extern inline void _WINE_FORWARD_WM_LBUTTONDOWN(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags, WNDPROC *fn) { /* return */ _FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, *fn); } #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _WINE_FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), &(fn)) #else #define FORWARD_WM_LBUTTONDOWN(hwnd, fDoubleClick, x, y, keyFlags, fn) \ _FORWARD_WM_LBUTTONDOWN((hwnd), (fDoubleClick), (x), (y), (keyFlags), (fn)) #endif Or something like that. I'm not even sure the __WINE__ is needed. I not sure that any Winelib application could possibly misuse the macros in such a way that the result is not semantically the same (type warnings/errors excluded of course). Note that it is quite easy to write script that automatically does this to avoid subtle bugs especially since the correct (almost) prototype is already before each macro. Like in the case above: /* void Cls_OnLButtonDown(HWND hwnd, BOOL fDoubleClick, int x, int y, UINT keyFlags) */ This will give us all the advantages of the "macros" without any typecasts that could possibly hide a type error. What do you say? Note that we don't have to implement the solution above right now either. Using the macros as they are will not gain us very much (except possible a cleaner looking code), true. However when we implement the type safe "macros" as described above we will immediately find any and all type errors concerning such code. Anway fixing windowsx.h to look like above will not be very difficult either so there is no real reason to wait is it? PS. As hinted above this will also work with most (all?) Winelib applications that happends to use the windowsx.h macros and enable the finding of subtle type errors in such applications.

1 0

Re: RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Alexandre Julliard 10 Aug '01

10 Aug '01

Patrik Stridvall <ps(a)leissner.se> writes: > So the question is: > Should we use the FORWARD_WM_* macros to avoid typecasts > (or rather avoid visable typecast) or should we not? > If not how should we fix the problems? I think it's better to avoid that. Hiding the typecasts in the macros doesn't really make things cleaner IMO. This is a case where the API design forces us to use a typecast, so we might as well make it explicit. Note that for the specific case of WM_GET/SETTEXT, it would be much better to use Get/SetWindowText which will do correct type checks. But for messages that don't have a corresponding function we have to do the typecast. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: Should we use the macros in windowsx.h to fix -DSTRICT warni ngs?
by Patrik Stridvall 10 Aug '01

10 Aug '01

This is not primarily a patch it is a RFC. I have experimented a bit with fixing the strict warnings. I have a few patch that I haven't submitted yet partly because I'm not 100% sure how all warnings should be fixed. Anyway, one large class of warnings is the ones cause by the window messaging functions. Like the one below: SendMessageW(lphc->hWndEdit, WM_SETTEXT, 0, (LPARAM)empty_stringW); This one unlike others this one does cause any warning with -DSTRICT because of the ugly cast, but the principle is the same. The only good way to fix this kind of problems that I can see is to use the FORWARD_WM_* macros in include/windowsx.h to write it like: FORWARD_WM_SETTEXT(lphc->hWndEdit, empty_stringW, SendMessageW); This works fine because the FORWARD_WM_SETTEXT macro look like this: #define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) Actually I lied this special case will not work fine since FORWARD_WM_SETTEXT uses TCHAR and friends. But that is not so important for the general principle. See below. Anyway, in some meaning the macros only hides the casts, but can casts really be avoided? We must cast to {W,L}PARAM at some time mustn't we? And the macros in windowsx.h is not that bad they cast to the correct type before the cast to {W,L}PARAM. This might help to find some bugs. Perhaps rewriting to macros as inline functions might help to? So the question is: Should we use the FORWARD_WM_* macros to avoid typecasts (or rather avoid visable typecast) or should we not? If not how should we fix the problems? And if we decide to use them, is patches like the one below to include/windowsx.h that fixes the TCHAR and friend problem acceptable or should we solve such problems in another way? PS. Alexandre: Feel free to apply the patch below if you agree. ---8<--- * include/windowsx.h: Include files used internally by Wine can't use the types TCHAR and friends. ---8<--- Index: wine/include/windowsx.h =================================================================== RCS file: /home/wine/wine/include/windowsx.h,v retrieving revision 1.7 diff -u -u -r1.7 windowsx.h --- wine/include/windowsx.h 2001/01/10 22:42:35 1.7 +++ wine/include/windowsx.h 2001/08/10 12:43:18 @@ -714,17 +714,37 @@ #define FORWARD_WM_ENABLE(hwnd, fEnable, fn) \ (void)(fn)((hwnd), WM_ENABLE, (WPARAM)(BOOL)(fEnable), 0L) +/* void Cls_OnSetTextA(HWND hwnd, LPCSTR lpszText) */ +#define HANDLE_WM_SETTEXTA(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTA(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCSTR)(lpszText)) + +/* void Cls_OnSetTextW(HWND hwnd, LPCWSTR lpszText) */ +#define HANDLE_WM_SETTEXTW(hwnd, wParam, lParam, fn) \ + ((fn)((hwnd), (LPCWSTR)(lParam)), 0L) +#define FORWARD_WM_SETTEXTW(hwnd, lpszText, fn) \ + (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCWSTR)(lpszText)) + /* void Cls_OnSetText(HWND hwnd, LPCTSTR lpszText) */ -#define HANDLE_WM_SETTEXT(hwnd, wParam, lParam, fn) \ - ((fn)((hwnd), (LPCTSTR)(lParam)), 0L) -#define FORWARD_WM_SETTEXT(hwnd, lpszText, fn) \ - (void)(fn)((hwnd), WM_SETTEXT, 0L, (LPARAM)(LPCTSTR)(lpszText)) +#define HANDLE_WM_SETTEXT WINELIB_NAME_AW(HANDLE_WM_SETTEXT) +#define FORWARD_WM_SETTEXT WINELIB_NAME_AW(FORWARD_WM_SETTEXT) + +/* INT Cls_OnGetTextA(HWND hwnd, int cchTextMax, LPSTR lpszText) */ +#define HANDLE_WM_GETTEXTA(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPSTR)(lParam)) +#define FORWARD_WM_GETTEXTA(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPSTR)(lpszText)) + +/* INT Cls_OnGetTextW(HWND hwnd, int cchTextMax, LPWSTR lpszText) */ +#define HANDLE_WM_GETTEXTW(hwnd, wParam, lParam, fn) \ + (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPWSTR)(lParam)) +#define FORWARD_WM_GETTEXTW(hwnd, cchTextMax, lpszText, fn) \ + (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPWSTR)(lpszText)) /* INT Cls_OnGetText(HWND hwnd, int cchTextMax, LPTSTR lpszText) */ -#define HANDLE_WM_GETTEXT(hwnd, wParam, lParam, fn) \ - (LRESULT)(DWORD)(int)(fn)((hwnd), (int)(wParam), (LPTSTR)(lParam)) -#define FORWARD_WM_GETTEXT(hwnd, cchTextMax, lpszText, fn) \ - (int)(DWORD)(fn)((hwnd), WM_GETTEXT, (WPARAM)(int)(cchTextMax), (LPARAM)(LPTSTR)(lpszText)) +#define HANDLE_WM_GETTEXT WINELIB_NAME_AW(HANDLE_WM_GETTEXT) +#define FORWARD_WM_GETTEXT WINELIB_NAME_AW(FORWARD_WM_GETTEXT) /* INT Cls_OnGetTextLength(HWND hwnd) */ #define HANDLE_WM_GETTEXTLENGTH(hwnd, wParam, lParam, fn) \

1 0

wine+mirc /rename confusiion bug
by mdew 10 Aug '01

10 Aug '01

make a empty file..place it the mirc dir... /rename y:\fake_windows\mirc\text.txt c:\mirc\text2.txt *** /rename: unable to rename 'y:\fake_windows\mirc\text.txt' to 'c:\mirc\text2.txt' $ ls text* -al -rw-r--r-- 1 mdew mdew 6 Aug 10 22:33 text.txt -rw-r--r-- 1 mdew mdew 6 Aug 10 22:36 text2.txt complains about it...yet it actually does it. -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

1 0

trouble with fonts (old, old problem)
by Mike McCormack 10 Aug '01

10 Aug '01

Hi All, i've got a problem with fonts in Netscape that's been around for a long time, while i've tried several times, unsuccessfully, to fix. When netscape 4.77 first loads, then loads an arbitary page, everything (text, buttons, comboboxes) is rendered incorrectly. If i go to another page, then hit the Back button, the page that was originally rendered incorrectly is now correct. All further renderings are correct for all pages. In my investigations (some time ago), i found that : * font enumeration functions returned different things on the first and second load of the same page. * i could correct the problem by changing the default ansi fixed font to helvetica i suspect that the wine loads extra X11 fonts between the first and second page viewings... but i don't know much about font handling in wine. i'll make some screen shots if anybody is interested. Any ideas? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Font scaling in PSDRV_EnumDeviceFonts
by Ian Pilcher 10 Aug '01

10 Aug '01

Can anyone point me to the Win32 API that ultimately calls the subject function? I'm trying to understand why it scales fonts to a 200 logical unit (I think) character cell. Is this completely arbitrary? Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: wineserver.pid
by Alexandre Julliard 09 Aug '01

09 Aug '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Hi all, > > some guy was running several different versions of wineservers for one > account via wrapper scripts. > And of course he had a hell of a hard time figuring out which wineserver to > kill for which application ;-) Why would you want to do that? Just kill the app and it will die on its own (and save everything too). I don't think encouraging people to kill the wineserver is a good idea. -- Alexandre Julliard julliard(a)winehq.com

1 0

winelib application debugging
by Vitaly Kuznetsov 09 Aug '01

09 Aug '01

Is there currently any way to debug winelib application? I read winedbg doc, but there are only samples for windows executables. -- Vitaly AKA Vitty mailto: vitty(a)dts.ru NetMail:2:5015/133.41

2 1

Today's CVS hangs on startup
by Ian Pilcher 09 Aug '01

09 Aug '01

The good news is that --debugmsg +all actually stops producing anything. Hopefully someone can look at the output below and figure out what's going on. Anyone else seen this? ... 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine,Eudora\EUDORA.EXE) -> Eudora (EUDORA) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_FindUnixName /home/pilcher/wine/Eudora,EUDORA.EXE 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000022c): returning 403c36c8 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine/Eudora,EUDORA.EXE) -> EUDORA.EXE (EUDORA.EXE) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_GetFullName returning /home/pilcher/wine/Eudora/EUDORA.EXE = C:\EUDORA\EUDORA.EXE 080689c0:trace:string:lstrcpynA (0x405f68e8, "C:\\EUDORA\\EUDORA.EXE", 260) 080689c0:trace:string:lstrcpynA (0x405f68ea, "/Eudora/EUDORA.EXE", 258) 080689c0:trace:module:GetModuleFileName16 01cf -> 'C:\Eudora\EUDORA.EXE' 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000004c): returning 403c3480 080689c0:trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x405f6820) 080689c0: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Wine\\Wine\\Config\\AppDefaults" ) Open key ERROR 080689c0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080689c0:trace:reg:NtOpenKey <- 0x0000 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"display",(nil),(nil),0x405f68f0,0x405f6818=268) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"display",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"display" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Managed",(nil),(nil),0x405f68e8,0x405f6814=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Managed",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Managed" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Desktop",(nil),(nil),0x405f68e8,0x405f6810=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Desktop",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Desktop" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"DXGrab",(nil),(nil),0x405f68e8,0x405f680c=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"DXGrab",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"DXGrab" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"UseDGA",(nil),(nil),0x405f68e8,0x405f6808=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"UseDGA",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"UseDGA" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"ScreenDepth",(nil),(nil),0x405f68e8,0x405f6804=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"ScreenDepth",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"ScreenDepth" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Synchronous",(nil),(nil),0x405f68e8,0x405f6800=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Synchronous",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Synchronous" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0: close_handle( handle=32 ) 080689c0: close_handle() = 0 { fd=-1 } 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

[Fwd: Re: x11drv port to win32 possible ?]
by Ian Pilcher 09 Aug '01

09 Aug '01

Rudi De Vos wrote: > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > Someone can correct me if I'm wrong, but I believe that Wine's built-in graphics drivers -- x11drv, ttydrv, and wineps -- interface with Wine's GDI code in a non-standard way. Alexandre has made some changes in this area recently, but I don't believe they've changed that fundamental fact. So to do what you're proposing, you would first have to modify Wine's GDI code to support one of Microsoft's 32-bit graphics driver interfaces. (Different Microsoft 32-bit OSes have different driver interfaces, BTW.) You could then update x11drv to use this interface. As Patrik pointed out, this is really outside the scope of the Wine project, but I do think that it would be valuable. In addition to the reasons you give above, it would be helpful in improving both the Wine driver code and the Wine GDI code. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

RE: x11drv port to win32 possible ?
by Patrik Stridvall 09 Aug '01

09 Aug '01

[You know you replied in private? Hmm, it doesn't seem to be private. Including list again, others might be intrested] > Perhaps the subject needed to be > X11drv insite function port to win32 possible ? I'm not sure this new title makes it clearer. But never mind. > A graphic driver would display the full desktop and not a single > application. True. > And wine is not needed to display anything. > This is currently used with the sunpci (intel coprocessor card in the > sparc boxes). > The video driver display the pc-screen as a xwindows or native on a > second monitor. I'm not sure I quite with you, but never mind, see below. > I want to create equivalent functions, but it seems that the functions > (X11DRV_...) make also use of the ntdll, userdll ... > I just want to know if it would be possible to recompile the > x11drv part > against the native dlls ( on win32 ). > Not the full x11drv, but only the functions mentioned in the > x11drv.spec > file. So I would be able to change the functions in win32 source code > and recompile with the X11DRV_.. functions. Possible, perhaps. However to me it just seems like a silly hack to use the X11DRV_ functions for that or at least to use them directly. Anyway, so what you really want to be able to compile Windows source code to a Windows binary that instead of using normal USER/GDI instead uses Wine's version of USER/GDI that using the X11DRV displays the application's Window(s) on a X-Terminal? Hmm. Intresting idea. Well, yes that would be possible to do with Wine, at least in theory. There is a lot a practical problems to be resolved for that to work. Just getting the non-core parts (especially USER/GDI and X11DRV) to compile and link to a DLL with the Windows headers will be an effort by itself. Actually getting it to work will be even worse, The USER (and to a lesser part even GDI) seems, eventhough I guess they can be made not to, to use the Wine server for some things, with means that you will either have to fix that or emulate the Wine server on Windows. It is propably not that hard to emulate it, but quite a lot of work regardless. Then you have the issue of getting the Windows versions of COMCTL32 and COMDLG32 DLL:s and similar DLL:s using your special versions of USER32 and GDI32 and not the Windows ones. I'm not sure Windows can be made to support this at all. It depends on exactly how library loading work. Hmm, perhaps it would be possible to "hook" LoadLibrary somehow. Anyway, I'm sorry to say that it will currently not, with the state Wine is now, be possible to do that without an enormous effort. Despite this I'm happy to say that I think it will be possible some day. However not until past Wine 1.0 or perhaps not even past Wine 1.x. Nice idea though.

1 0

RE: x11drv port to win32 possible ?
by Patrik Stridvall 09 Aug '01

09 Aug '01

> Has anyone already try to compile it with VC++. > > Using the win32X11 port from http://sources.redhat.com/win32-x11/ and > microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and > wineclipsrv.exe. > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > > 1)If we can compile that dll, can we recompile a win32 app so it > runs on a pc and display on a X-terminal? > 2)Can multiple users run the same app on win95/98 and display on diff > X-terminals? I think what I think you are proposing is currently entirely out of the scope of the Wine project. Wine is currently not designed for this. Compiling some of the non-core DLL:s like COMCTL32, COMDLG32 and others might be meaningful for test purposes, but the core stuff like the is simply not possible and it is not needed since Windows already has its own implementation of them that can used in the testing the non-core DLL:s. In short, what you are proposing is intresting but it has currently little to do with the Wine project. What you want to do is the write a Windows "graphic card" driver that display the result on an X-Terminal. While you certainly can (and are indeed legally allowed to do) use part of the x11drv to do this, I think most of the X11DRV is to high level to be useful. Sure someday when your "graphic card" driver works good we might consider redesigning Wine to use the Windows "graphic card" driver interface, but it will certainly not not be done before Wine 1.0 or even Wine 1.x. Perhaps Wine 2.0 might be a good point to merge such things with Wine, assuming of course that you or somebody else implements such a thing and releases it under an acceptable license (preferably the Wine license, the new one that is).

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