(no subject)
I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with wine InstMSI.exe). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:0009 EBX: ECX:80002b08 EDX:000c ESI:80002b08 EDI: Stack dump: 0x7fc8fd24: 0048 004d5b8f 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 0x7fc8fd64: 7fc8fd84 00bcc611 004d 0001 0x7fc8fd74: 0001 0001 0001 00bfd1b0 0200: sel=1007 base=7befc000 limit=1fff 32-bit rw- Backtrace: =1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl0x14(%esi),%eax Modules: Module Address Debug info Name (43 modules) ELF 0x0025f000-00299000 Deferredadvapi32elf \-PE 0x0027-00299000 \ advapi32 ELF 0x002c8000-002cd000 Deferredlibxxf86vm.so.1 ELF 0x002d2000-002ee000 Deferredld-linux.so.2 ELF 0x002ee000-0031c000 Deferredlibfontconfig.so.1 ELF 0x002ee000-0031c000 Deferredlibfontconfig.so.1 ELF 0x002f4000-0041e000 Export libc.so.6 ELF 0x00346000-0043c000 Deferredlibwine_unicode.so.1 ELF 0x0042-00426000 Deferredlibxxf86dga.so.1 ELF 0x0042-00426000 Deferredlibxxf86dga.so.1 ELF 0x00446000-0044a000 Deferredlibdl.so.2 ELF 0x0044a000-004cb000 Deferredgdi32elf \-PE 0x0044c000-0045f000 \ libz.so.1 \-PE 0x0046-004cb000 \ gdi32 \-PE 0x0046-004cb000 \ gdi32 PE 0x004d-00522000 Deferredrpcrt4 ELF 0x00537000-00549000 Deferredlibpthread.so.0 ELF 0x0054b000-0055a000 Deferredlibxext.so.6 ELF 0x0055c000-00565000 Deferredlibsm.so.6 ELF 0x00567000-00581000 Deferredlibice.so.6 ELF 0x00583000-005a2000 Deferredlibexpat.so.0 ELF 0x00583000-005a2000 Deferredlibexpat.so.0 PE 0x005b-0067e000 DIA kernel32 PE 0x005b-0067e000 DIA kernel32 PE 0x005b-0067e000 DIA kernel32 PE 0x0068-0086c000 Deferredmsi ELF 0x0086c000-0097a000 Deferreduser32elf \-PE 0x0089-0097a000 \ user32 \-PE 0x0089-0097a000 \ user32 ELF 0x00975000-009f Deferredlibgl.so.1 ELF 0x00975000-009f Deferredlibgl.so.1 PE 0x009f-00a59000 Deferredwinex11 ELF 0x00b2d000-00b4c000 Deferredximcp.so.2 ELF 0x00b4c000-00b67000 Deferredimm32elf \-PE 0x00b5-00b67000 \ imm32 ELF 0x00b99000-00c09000 Stabs ntdllelf \-PE 0x00bb-00c09000 \ ntdll ELF 0x00ea3000-00ea5000 Deferredxlcutf8load.so.2 ELF 0x00ef1000-00f07000 Deferredmsiexecelf \-PE 0x00f0-00f07000 \ msiexec ELF 0x00fed000-00ff8000 Deferredlibnss_files.so.2 PE 0x65f0-65fc2000 Deferredole32 ELF 0x7bf0-7bf03000 Deferredwine-loader Threads: process tid prio (all id:s are in hex) 0009 (D) C:\windows\system32\MSIEXEC.EXE 000c0 == 0047 00080 001e 00262
Re: JDK
Curro Amores wrote: I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with wine InstMSI.exe). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:0009 EBX: ECX:80002b08 EDX:000c ESI:80002b08 EDI: Stack dump: 0x7fc8fd24: 0048 004d5b8f 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 0x7fc8fd64: 7fc8fd84 00bcc611 004d 0001 0x7fc8fd74: 0001 0001 0001 00bfd1b0 0200: sel=1007 base=7befc000 limit=1fff 32-bit rw- Backtrace: =1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl0x14(%esi),%eax ... PE 0x004d-00522000 Deferredrpcrt4 PE 0x0068-0086c000 Deferredmsi PE 0x65f0-65fc2000 Deferredole32 This isn't a user's list, but you might want to start by setting the above three DLLs to builtin. I can't fix bugs in native DLLs, but I can in Wine's. -- Rob Shearman
Re: JDK
Curro Amores wrote: I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with wine InstMSI.exe). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:0009 EBX: ECX:80002b08 EDX:000c ESI:80002b08 EDI: Stack dump: 0x7fc8fd24: 0048 004d5b8f 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 0x7fc8fd64: 7fc8fd84 00bcc611 004d 0001 0x7fc8fd74: 0001 0001 0001 00bfd1b0 0200: sel=1007 base=7befc000 limit=1fff 32-bit rw- Backtrace: =1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl0x14(%esi),%eax ... PE 0x004d-00522000 Deferredrpcrt4 PE 0x0068-0086c000 Deferredmsi PE 0x65f0-65fc2000 Deferredole32 This isn't a user's list, but you might want to start by setting the above three DLLs to builtin. I can't fix bugs in native DLLs, but I can in Wine's. -- Rob Shearman I've just tried the installation (with CVS of yesterday on a pretty clean wine install) and don't see any issues. I didn't check if it's functional though. I don't have any native dll's btw. Paul.
Re: JDK
Robert == Robert Shearman [EMAIL PROTECTED] writes: Robert Curro Amores wrote: I get this error when trying to install j2se with wine, i think is PE 0x004d-00522000 Deferred rpcrt4 PE 0x0068-0086c000 Deferred msi PE 0x65f0-65fc2000 Deferred ole32 Robert This isn't a user's list, but you might want to start by setting Robert the above three DLLs to builtin. I can't fix bugs in native Robert DLLs, but I can in Wine's. Robert, as we are on the devel list, can you tell what bug in what native library you see? Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: JDK
Uwe Bonnes wrote: Robert == Robert Shearman [EMAIL PROTECTED] writes: Robert Curro Amores wrote: I get this error when trying to install j2se with wine, i think is PE 0x004d-00522000 Deferred rpcrt4 PE 0x0068-0086c000 Deferred msi PE 0x65f0-65fc2000 Deferred ole32 Robert This isn't a user's list, but you might want to start by setting Robert the above three DLLs to builtin. I can't fix bugs in native Robert DLLs, but I can in Wine's. Robert, as we are on the devel list, can you tell what bug in what native library you see? It expects there to be a Win9x shared heap present, but it isn't under NT or Wine. It makes invalid assumptions about the environment in which it is running. -- Rob Shearman
Loader Optimization Benchmarks
Hi, I thought it would be good to post some benchmarks for the patch I just sent to wine-patches: http://www.winehq.org/pipermail/wine-patches/2006-January/023323.html I tested the loader code using the following in both cases: int i; DWORD dwTicksAfter; DWORD dwTicksBefore = GetTickCount(); for (i = 0; i 1000; i++) LoadLibrary(ole32); dwTicksAfter = GetTickCount(); trace(time taken = %ld ms\n, dwTicksAfter - dwTicksBefore); Before the patch: time taken = 658 ms time taken = 661 ms time taken = 661 ms time taken = 658 ms time taken = 659 ms After the patch was applied: time taken = 12 ms time taken = 12 ms time taken = 12 ms time taken = 13 ms time taken = 12 ms So it should be obvious that there are some very real gains from using this patch in the test case. You might think that an application loading a DLL 1000 times is very unlikely, but bear in mind that the ole32 marshal tests load ole32 76 times. It is therefore conceivable that something more complex like InstallShield could load ole32 over 100 times. -- Rob Shearman
Re: Loader Optimization
Robert Shearman [EMAIL PROTECTED] writes: ChangeLog: Optimize for the case where a DLL with no path is requested and it is already loaded. This change is correct since RtlDosSearchPath_U did not change the path being looked at - if libname contains no path then file_part will be the same as libname. Yes, but the current code checks for the full name first and your patch doesn't, so it will change the behavior if we have two modules with the same base name. This will need some test cases. -- Alexandre Julliard [EMAIL PROTECTED]
Re: COMCTL32: Invalidate the entire progress bar any time it changes.
Mike McCormack [EMAIL PROTECTED] wrote: This is an old patch, but the code that is in comctl32 now is wrong. This fixes it, and there's no known regressions. Unfortunately there's no way to fix this efficiently. Mike ChangeLog: Invalidate the entire progress bar any time it changes. Fixes the progress bar so it paints properly in InstallShield. My (old) tests show that native comctl32 invalidates the entire progress bar once it changes, so that change is OK. But it's smart enough to not invalidate the background if new bar position is larger than an old one, that reduces the flicker. -- Dmitry.
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/10/06, Molle Bestefich [EMAIL PROTECTED] wrote: Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/ Trac looks interesting, but the demo there seems a bit messy. Unfortunately it uses SQLite, which may not be able to effectively handle the huge needs of wine's bug tracking. It says they will try implement support for other sql servers in later versions, but currently it doesn't. n0dalus.
Re: daily winetest generation
On Monday 09 Jan 2006 21:50, Rolf Kalbermatter wrote: Paul Millar wrote: The problem above (at the beginning of this year) was with a missing GUID in the compiler, which is now fixed. Could you tell me what GUID it was. Certainly, it was IID_IHttpNegotiate2, as defined by: DEFINE_GUID(IID_IHttpNegotiate2,0x4f9f9fcb,0xe0f4,0x48eb,0xb7,0xab,0xfa,0x2e,0xa9,0x36,0x5c,0 xb4); I'm currently in the process of trying to get compilation of DLLs working again with MSVC and the winapi tools and noticed a specific issue with GUIDs. Maybe I can learn a bit here. If it helps any, I've tied together the current set of patches against MinGW's w32api. They are available from here: http://www.astro.gla.ac.uk/users/paulm/Cross/mingw-w32api-patches-2006-01-09.tar.gz (BTW, Hans maintains RPMs of modified MinGW here: http://mirzam.it.vu.nl/mingw/ ) For instance the GUIDs IID_IAVIStreaming and CLSID_AVIFile used in avifil32.dll are put by wine in the uuid.lib/dll file but the two MS SDKs I tried do not seem to provide these exports in either uuid.lib nor vfw32.lib(avifil32.dll). Sorry, can't help you with SDKs. Both are defined in avifil32.def in MinGW's w32api v3.3. HTH, Paul. pgpSx7GTHgvPU.pgp Description: PGP signature
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/10/06, Molle Bestefich [EMAIL PROTECTED] wrote: Unfortunately it uses SQLite, which may not be able to effectively handle the huge needs of wine's bug tracking. It says they will try implement support for other sql servers in later versions, but currently it doesn't. Bull... There are commercial products out there that handle millions of records of data per hour running on SQLite. I can't quite imagine what you're afraid of. In my experience SQLite has been several times slower than a well-configured MySQL server when dealing with large record sets, complex table structures and blob data. Maybe the newer versions of SQLite have improved on this though. n0dalus.
test exploit for WMF / SETABORTPROC vulnerability
Hi, If someone needs an exploit for the WMF / SETABORTPROC vulnerability that works under WINE (0.9.5) to verify fixed packages, feel free to mail me offline. Ciao, Marcus
Re: Loader Optimization
Alexandre Julliard wrote: Robert Shearman [EMAIL PROTECTED] writes: ChangeLog: Optimize for the case where a DLL with no path is requested and it is already loaded. This change is correct since RtlDosSearchPath_U did not change the path being looked at - if libname contains no path then file_part will be the same as libname. Yes, but the current code checks for the full name first and your patch doesn't, so it will change the behavior if we have two modules with the same base name. This will need some test cases. What sort of tests do you want? I don't think I'll be able to come up with anything that can be put into the Wine test framework. -- Rob Shearman
Re: Loader Optimization
Robert Shearman [EMAIL PROTECTED] writes: What sort of tests do you want? I don't think I'll be able to come up with anything that can be put into the Wine test framework. Agreed, it's probably not possible to put that in the test framework since it will need native dlls. All we really need is a small test app that we can run on Windows to determine the proper behavior. -- Alexandre Julliard [EMAIL PROTECTED]
RFC: implementation of driver functionality in msacm (RESEND)
(resent because previous attempt never appeared in wine-devel) This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso wine-msacm-acmDriver.patch.gz Description: GNU Zip compressed data
Re: ntdll/tests: Load test on win95 again
Detlef Riekenberg [EMAIL PROTECTED] writes: Changelog: - ntdll/tests: Load test on win95 again (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RESEND: winecfg: Added Use PRIMARY selection option
Phil Krylov [EMAIL PROTECTED] writes: ChangeLog: Added support for Use PRIMARY selection clipboard option. I don't think we want a new property sheet page for that, it should go with the other X11 options. -- Alexandre Julliard [EMAIL PROTECTED]
static COM VTables?
Hello, I just read the constify data todo, and I thought it would be good to make the VTables in my ddraw implementation const. The old ddraw implementation also declares them static. Is there any advantage in it? My C book just says that they can only be referenced from the local module, which is correct. But are there any other effects? Stefan pgprHxSotinLc.pgp Description: PGP signature
Re: Winelib debugging with eclipse in fc4
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote: you could (not tested) alternatively: - set winegdb --gdb as the name for executing gdb - not reset the AeDebug key - set the executable to be the real exec (+ .so extension if run from the build tree) that should work also you would this way: - keep all the preloader stuff, so that your memory layout is better (and the same than when run from command line) - still be compatible with the segfault stuff I'll try that and let you know what I find once my development tree gets usable again. It's pretty hacked up right now. Thanks ... mo
Re: static COM VTables?
Stefan Dösinger wrote: Hello, I just read the constify data todo, and I thought it would be good to make the VTables in my ddraw implementation const. The old ddraw implementation also declares them static. Is there any advantage in it? My C book just says that they can only be referenced from the local module, which is correct. But are there any other effects? No, that is the only direct effect. However, as it can only be referenced from the one module then the compiler will warn if it is not used, leading to less dead code. Also, it doesn't put a symbol in the ELF name table, which means loading the DLL will be slightly faster. -- Rob Shearman
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On Mon, Jan 09, 2006 at 08:42:06PM -0800, Scott Ritchie wrote: Forums are absolutely a good idea. (...) The reason is the same reason I post to these forums - they're far more usable, well-sorted, and accessable than a mailing list. The problem is that (AFAIK) most if not all Wine developpers do not share at all this view (at last for me nothing beats either a mailing list or a newsgroups :-) ). So you will have a nice forum full of Wine questions and no developpers who read them to answer the posts because no-one will care actually reading the forum. I may be wrong though thinking that all other Wine developpers are 'dinosaurs' like me :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Starter projects for new Wine contributors?
Am Montag, den 09.01.2006, 21:02 -0500 schrieb Al Tobey: I'm looking for suggestions for starter projects for new contributors that would take something like a week to do, and wouldn't require much knowledge of Wine ahead of time. Tests! Another way is: Fixing Tests, that currently fail on Windows. Test-Results: http://test.winehq.org/data Binaries: http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ The MinGW Cross-Compiler is used to build the Binaries I'm building native Windows-EXE using the Cross-Compiler-Packages from Hans ( http://mirzam.it.vu.nl/mingw/ ) A recent Example was the failure of ntdll.dll:exception on Win95-WinME - Run the Test on Windows to find the Problem - Fix the Problem - Build and run the Wine-Test: make -C dlls/ntdll/tests/ test - Build the Windows Test: make -C dlls/ntdll/tests/ crosstest - Run ntdll_crosstest.exe on all available Windows-Versions (I'm using qemu for this) - Create the useful_name.diff - Mail the Patch to wine-patches - Wait for Commit http://www.winehq.org/site/docs/winedev-guide/testing -- By By ... ... Detlef
Re: RFC: implementation of driver functionality in msacm (RESEND)
Alex Villacís Lasso wrote: (resent because previous attempt never appeared in wine-devel) This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. Even for review it's easier by small chunks... The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() - you shouldn't compute the length of the necessary unicode buffer with strlen * sizeof(WCHAR). See rest of the code for good example - when you free lParamW, lParamW can be another non null value (a window handle for example) and you shouldn't free it * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) - I wonder if we should really (internally) register the nofication windows the same ways as the other drivers... this is only used for notification (one way). I'd rather use a separate internal type * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes - MSDN seems to state that differed notification is actually a counter, not a simple boolean (whereas enable/disable is a boolean) * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs this seems rather hackish. did you actually tested this on Windows ? Moreover, the size bits look especially suspicious. Where did you get the 16 value from ? * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. this shouldn't be done that way, but rather by reimplementing senddrivermessage in msacm32 A+ -- Eric Pouech
Re: RFC: implementation of driver functionality in msacm (RESEND)
Eric Pouech wrote: * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes - MSDN seems to state that differed notification is actually a counter, not a simple boolean (whereas enable/disable is a boolean) I have just read the MSDN web page, and I see no remark that suggests that deferred notification should behave as a counter instead of a simple on/off flag. Or maybe I am reading the page incorrectly... * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs this seems rather hackish. did you actually tested this on Windows ? Moreover, the size bits look especially suspicious. Where did you get the 16 value from ? I tested the native msacm32.dll from Windows 98 SE on Wine, and it reported a 16-byte struct size to the winemp3 codec. Since the goal was to allow native codecs no reason at all for not displaying the configuration dialog, I decided to use that size, even when the structure size in Wine is only 12 bytes. * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. this shouldn't be done that way, but rather by reimplementing senddrivermessage in msacm32 That was the very thing I didn't want to do. So, while we are at it, should it be reimplemented for all codecs, or just the ones supplied by the application? Native msacm32 seems to relay to winmm for registered codecs, since I can see calls to SendDriverMessage(). Alex Villacís Lasso
Re: WineDbg: Implemented harware assisted breakpoints.
Eric Pouech wrote: one can now set a hardware breakpoint in winedbg (it will not insert an INT 3 command in the code, but rather use the x86 debug registers). handy for debugging trashed code for example all the syntaxic forms of the 'break' command can be used for this new hbreak command. (only works on x86 for now) ChangeLog: Implemented harware assisted breakpoints merci de ne pas appliquer tel quel. J'ai une nouvelle version moins buggée. A+ -- Eric Pouech
Re: RESEND: winecfg: Added Use PRIMARY selection option
On Tue, 10 Jan 2006 20:23:20 +0100 Alexandre Julliard [EMAIL PROTECTED] wrote: Phil Krylov [EMAIL PROTECTED] writes: ChangeLog: Added support for Use PRIMARY selection clipboard option. I don't think we want a new property sheet page for that, it should go with the other X11 options. Initially I did it that way, but: 1) The X11 option page is named Graphics, and clipboard is not graphics ;) 2) There's no free space on the Graphics page. Should I make it (and the whole winecfg window) larger? -- Ph.
Re: RFC: implementation of driver functionality in msacm (RESEND)
Eric Pouech wrote:
Alex Villacís Lasso wrote:
Eric Pouech wrote:
* Implementation of broadcasts to notification windows on driver
add/remove, enabling/disabling, and priority changes
- MSDN seems to state that differed notification is actually a
counter, not a simple boolean (whereas enable/disable is a boolean)
I have just read the MSDN web page, and I see no remark that suggests
that deferred notification should behave as a counter instead of a
simple on/off flag. Or maybe I am reading the page incorrectly...
well...
ACM_DRIVERPRIORITYF_END Calling task wants to reenable change
notification broadcasts. An application must call acmDriverPriority
with ACM_DRIVERPRIORITYF_END for each successful call with the
ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL,
dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can
be set.
... then I need new glasses :-)
* Fix for implementation quirks of acmDriverMessage() in order to
allow native codecs to display configuration dialogs
this seems rather hackish. did you actually tested this on Windows ?
Moreover, the size bits look especially suspicious. Where did you
get the 16 value from ?
I tested the native msacm32.dll from Windows 98 SE on Wine, and it
reported a 16-byte struct size to the winemp3 codec.
how do you know it's a 16 byte struct? there's nothing in the passed
information that tells you it's 16 bytes AFAICS
Yes, there is:
(begin MSDN quote)
DRV_CONFIGURE
Directs the installable driver to display its configuration dialog box
and let the user specify new settings for the given installable driver
instance.
*Parameters*
/dwDriverId/
Identifier of the installable driver. This is the same value previously
returned by the driver from the *DRV_OPEN*
http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp
message.
/hdrvr/
Handle of the installable driver instance.
/lParam1/
Handle of the parent window. This window is used as the parent window
for the configuration dialog box.
/lParam2/
Address of a *DRVCONFIGINFO*
http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_str.asp
structure or NULL. If the structure is given, it contains the names of
the registry key and value associated with the driver.
DRVCONFIGINFO
Contains the registry key and value names associated with the
installable driver.
|typedef struct tagDRVCONFIGINFO {
DWORD dwDCISize;
LPCWSTR lpszDCISectionName;
LPCWSTR lpszDCIAliasName;
} DRVCONFIGINFO;
|
*Members*
*dwDCISize*
Size of the structure, in bytes.
*lpszDCISectionName*
Address of a null-terminated, wide-character string specifying the name
of the registry key associated with the driver.
*lpszDCIAliasName*
Address of a null-terminated, wide-character string specifying the name
of the registry value associated with the driver.
(end MSDN quote)
I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to
codecs, in particular the dwDCISize field. Even when the sum of all
fields in the structure declaration yields 12 bytes, dwDCISize holds a
value of 16 when supplied by native msacm32.dll. So, I used the same
value in order to mimic native as close as possible.
Alex Villacís Lasso
Re: RESEND: winecfg: Added Use PRIMARY selection option
Phil Krylov [EMAIL PROTECTED] writes: Initially I did it that way, but: 1) The X11 option page is named Graphics, and clipboard is not graphics ;) DXGrab is not really graphics either... maybe the page should be named windowing or something along those lines. 2) There's no free space on the Graphics page. Should I make it (and the whole winecfg window) larger? There's a lot of text in there that could be moved somewhere else, like a tooltip or an online help. Also the screen depth option should probably be removed, it's quite useless. -- Alexandre Julliard [EMAIL PROTECTED]
Mozilla ActiveX Control -- Browser not in a valid state
Hi,
I have a Borland C++ Builder app that is a simple FORM with a TCppWebBrowser
and a button. I have two callbacks, one when the form is created, and one
when the user pushes the button. Both callbacks just navigate to google.
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
CppWebBrowser1-Navigate(WideString(http://www.google.com;));
}
void __fastcall TForm1::DoIt1Click(TObject *Sender)
{
CppWebBrowser1-Navigate(WideString(http://www.google.com;));
}
On Windows this works as expected. When the form is displayed, google is
displayed in the browser. Whenever you push the button the browser is
reloaded.
On Wine with the Mozilla ActiveX Control v1.7.12, when the form is first
loaded nothing is displayed. WINEDEBUG=+ole shows Browser is not in a valid
state.
Pushing the button subsequent times reloads the web site as expected.
Before I start digging deeper, I was hoping somebody might have some insight
to lead me down the correct path.
Thanks!
Phil
Re: ntdll/tests: Load test on win95 again
Am Dienstag, den 10.01.2006, 20:14 +0100 schrieb Alexandre Julliard: - ntdll/tests: Load test on win95 again (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. I asked the Author of this Tests (Vitaliy) for Help: --- cut --- winspool: ntdll_test.exe does not load on win95 and NT3.51, because CreateWaitableTimerA does not exist vitamin: ok, when you fixed them did you ran them on win9x? winspool: with my Patch, the tests load and some tests work on win9x (generated, and a little more) vitamin: ;-) vitamin: useless anyway winspool:is it possible to move the affected Tests somewhere in kernel32/tests/ vitamin: no, vitamin: those tests _have to be there_ vitamin: That's what it tests (OM) --- cut --- Removing the kernel32-functions out of ntdll_tests.exe will result in moving nearly the complete OM-test to kernel32/tests, but the OM is located in ntdll. This does not match. Any Hints? Since NT3.51 and Win95 are unable to load the current ntdll_test.exe, are we in the Situation to drop WRT-Support for NT3.x and Win95? While trying to run winetest-latest.exe, i found several failing Tests (no counter or failed on the WRT-Result-Page). I picked this one as a start. -- By By ... ... Detlef
Need help to fix a failing test
Hi folks, As far as I can see, secur32 tests are failing on all windows platforms right now. (http://test.winehq.org/data/200601101000/) Now, this seems to be due to the following: main.c:475: Test failed: cbMaxToken for NTLM is 1904, not 12000. I'm pretty sure that I got the 12000 from my win2k system when I compiled the test code there using the platform sdk that was current this july. Now, I have no clue where the 1904 comes from, but if windows really uses a cbMaxToken of 1904, I need to fix that in my code (I couldn't use the 12000 I thought I had to implement before due to implementation restrictions. I can easily work with 1904, if those are correct.) Still, I'm sure I didn't pull the 12000 out of my sleeve. Could I ask someone who runs msvc and a platform sdk to build the secur32 tests, run them on any windows box and send the results to me? Thanks in advance, Kai -- Kai Blin, (blin at gmx dot net) Are you mentally here at Pizza Hut??
RFC: implementation of driver functionality in msacm
This patch is the preliminary result of some work I have been doing in
order to add missing functionality to builtin msacm32.dll. I am
submitting this to wine-devel rather than wine-patches, and in one big
patch rather than several because I would like comments on some choices
I made while adding features. The following is the list of features
added by the patch:
* Implementation of acmDriverAddW(), and delegation of acmDriverAddA()
to acmDriverAddW()
* Working implementation of modes of operation of acmDriverAdd[AW]: add
driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver
by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add
notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND)
* Implementation of broadcasts to notification windows on driver
add/remove, enabling/disabling, and priority changes
* Fix for implementation quirks of acmDriverMessage() in order to allow
native codecs to display configuration dialogs
* Working implementation of acmDriverPriority(), with support of delayed
notification broadcasts (for one process only). Includes saving new
priorities and enabled status to registry
* Loading of codec priorities and enabled status from registry
* Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics()
I must note that in order to provide support for acmDriverAddW() in
ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an
application-supplied module with an application-supplied driverProc as a
full-blown winmm driver. Therefore, the patch includes a new procedure
in winmm called wineAddDriver(), that instructs winmm to build a hDrvr
from a supplied hModule/driverProc pair, rather than loading both from a
DLL, as OpenDriver() does. This allows the rest of the code to continue
using SendDriverMessage() as usual.
Alex Villacís Lasso
diff -ur wine-0.9.5-cvs/dlls/msacm/driver.c wine-0.9.5-cvs-patch/dlls/msacm/driver.c
--- wine-0.9.5-cvs/dlls/msacm/driver.c 2005-12-20 10:17:52.0 -0500
+++ wine-0.9.5-cvs-patch/dlls/msacm/driver.c 2006-01-09 21:59:49.0 -0500
@@ -40,6 +40,7 @@
#include msacmdrv.h
#include wineacm.h
#include wine/debug.h
+#include wine/unicode.h
WINE_DEFAULT_DEBUG_CHANNEL(msacm);
@@ -49,6 +50,10 @@
MMRESULT WINAPI acmDriverAddA(PHACMDRIVERID phadid, HINSTANCE hinstModule,
LPARAM lParam, DWORD dwPriority, DWORD fdwAdd)
{
+MMRESULT resultW;
+WCHAR * driverW = NULL;
+LPARAM lParamW = lParam;
+
TRACE((%p, %p, %08lx, %08lx, %08lx)\n,
phadid, hinstModule, lParam, dwPriority, fdwAdd);
@@ -72,30 +77,100 @@
return MMSYSERR_INVALFLAG;
}
-/* FIXME: in fact, should GetModuleFileName(hinstModule) and do a
- * LoadDriver on it, to be sure we can call SendDriverMessage on the
- * hDrvr handle.
- */
-*phadid = (HACMDRIVERID) MSACM_RegisterDriver(NULL, NULL, hinstModule);
-
-/* FIXME: lParam, dwPriority and fdwAdd ignored */
+/* A-W translation of name */
+if ((fdwAdd ACM_DRIVERADDF_TYPEMASK) == ACM_DRIVERADDF_NAME) {
+unsigned long len = strlen((LPSTR)lParam) + 1;
+driverW = HeapAlloc(MSACM_hHeap, 0, len * sizeof(WCHAR));
+if (!driverW) return MMSYSERR_NOMEM;
+MultiByteToWideChar(CP_ACP, 0, (LPSTR)lParam, -1, driverW, len);
+lParamW = (LPARAM)driverW;
+}
-return MMSYSERR_NOERROR;
-}
+resultW = acmDriverAddW(phadid, hinstModule, lParamW, dwPriority, fdwAdd);
+if ((WCHAR *)lParamW != NULL) HeapFree(MSACM_hHeap, 0, driverW);
+return resultW;
+}
/***
* acmDriverAddW (MSACM32.@)
- * FIXME
- * Not implemented
+ *
*/
MMRESULT WINAPI acmDriverAddW(PHACMDRIVERID phadid, HINSTANCE hinstModule,
LPARAM lParam, DWORD dwPriority, DWORD fdwAdd)
{
-FIXME((%p, %p, %ld, %ld, %ld): stub\n,
- phadid, hinstModule, lParam, dwPriority, fdwAdd);
+TRACE((%p, %p, %08lx, %08lx, %08lx)\n,
+ phadid, hinstModule, lParam, dwPriority, fdwAdd);
+
+if (!phadid) {
+WARN(invalid parameter\n);
+ return MMSYSERR_INVALPARAM;
+}
+
+/* Check if any unknown flags */
+if (fdwAdd
+ ~(ACM_DRIVERADDF_FUNCTION|ACM_DRIVERADDF_NOTIFYHWND|
+ ACM_DRIVERADDF_GLOBAL)) {
+WARN(invalid flag\n);
+ return MMSYSERR_INVALFLAG;
+}
-SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
-return MMSYSERR_ERROR;
+/* Check if any incompatible flags */
+if ((fdwAdd ACM_DRIVERADDF_FUNCTION)
+ (fdwAdd ACM_DRIVERADDF_NOTIFYHWND)) {
+WARN(invalid flag\n);
+ return MMSYSERR_INVALFLAG;
+}
+
+switch (fdwAdd ACM_DRIVERADDF_TYPEMASK) {
+case ACM_DRIVERADDF_NAME:
+/*
+hInstModule (unused)
+lParam name of value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
+dwPriority (unused, set to 0)
+ */
+*phadid = (HACMDRIVERID)
Re: ntdll/tests: Load test on win95 again
Tuesday, January 10, 2006, 4:00:51 PM, Detlef Riekenberg wrote: Am Dienstag, den 10.01.2006, 20:14 +0100 schrieb Alexandre Julliard: - ntdll/tests: Load test on win95 again (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. [snip] Removing the kernel32-functions out of ntdll_tests.exe will result in moving nearly the complete OM-test to kernel32/tests, but the OM is located in ntdll. This does not match. Those tests cover kernel32.dll, ntdll and OM in the wineserver. So I've put them in the middle g. They could be moved to kernel, but then it will import same number of ntdll functions. So I don't really see a reason to move them around. But rather keep all the object manager specific tests in the one place Since NT3.51 and Win95 are unable to load the current ntdll_test.exe, are we in the Situation to drop WRT-Support for NT3.x and Win95? Why? ntdll tests just won't load. But everything else will work. I'm not really sure how usefull those results will be anyway. Vitaliy
Regression caused by ntdll: Check file size when mapping image sections to avoid SIGBUS errors.
On Wed, 4 Jan 2006 08:21, Alexandre Julliard wrote: Module: wine Branch: refs/heads/master Commit: 67f2a36ce3725a52b79ed618964244cc96ae ... status = STATUS_INVALID_IMAGE_FORMAT; /* generic error */ +if (header_size st.st_size) goto error; if (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED | ... This change prevents Wine from loading Win32 executables that are less than 64K long. header_size is 65536, but st.st_size is less than that. -- Troy Rollo - [EMAIL PROTECTED]
Re: PATCH/RFC: defer OLE apartment window creation
Marcus Meissner wrote:
On Wed, Dec 21, 2005 at 02:55:14AM +, Robert Shearman wrote:
Marcus Meissner wrote:
@@ -257,6 +254,15 @@
return apt;
}
+void make_apartment_window(APARTMENT *apt) {
+if (apt-win) return;
+if (!(apt-model COINIT_APARTMENTTHREADED))
+return;
+apt-win = CreateWindowW(wszAptWinClass, NULL, 0,
+ 0, 0, 0, 0,
+ 0, 0, OLE32_hInstance, NULL);
+}
+
This isn't thread-safe. It would also be better to make this an accessor
function for the win field of struct apartment and fix up all callers to
use this. I still have to verify on Windows whether this is what it does
or whether it does something funny with message loops.
I lack the time and testing abilities to do this right now (and now
on xmas break).
Its just a quick hack to get Google Earth running.
Can you update to latest CVS and confirm that this issue is fixed now?
--
Rob Shearman
Re: advpack: Implement ExtractFiles
James Hawkins wrote: What is the policy about attaching changes to tests that pass because of a patch sent in? Should I also diff the tests? There's a higher level policy of all changes should be atomic, which requires Wine to be in a working state before and after each change, so yes, you should update tests that pass with the patch that makes them pass. If you're adding new tests, it makes sense to send them in a seperate patch after the patch that implements functionality to make the new tests pass. Mike
