September 2005 - Wine-Devel

Re: http://cvs.winehq.org/patch.py?id=19964
by Juan Lang Sept. 4, 2005

Sept. 4, 2005

> this latest change to the shellpath test produces the attached error on > Windows XP. Haven't looked into this further. Damn. Alexandre, would you mind backing out this patch? It needs more work. http://cvs.winehq.org/patch.py?id=19964 Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

winedebug/gdb crashes
by Simon Kissane Sept. 4, 2005

Sept. 4, 2005

Hi Using latest wine CVS (checked out today), trying to debug the PackageForTheWeb self-extracting EXE that MS uses to distribute MSDE 2000.... The EXE works fine (albeit with some visual bugs) when running under plain wine instead of winedebug.... Anyone have any idea what might be wrong? (I am very new to wine, although I've been following the wine-devel archives for a while...) Cheers Simon Kissane ===== winedebug window ====== > winedbg --gdb --no-start z:/home/skissane/downloads/MSDE2000A.exe 0000001b:0000001c: create process 'Z:\home\skissane\downloads\MSDE2000A.exe'/0x7fff003c @0040ce00 (0<0>) 0000001b:0000001c: create thread I @0040ce00 target remote localhost:32815 0000001b:0000001c: loads DLL c:\windows\system\ntdll.dll @00840000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\kernel32.dll @00e50000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\advapi32.dll @00770000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\gdi32.dll @00370000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\user32.dll @00270000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\comctl32.dll @00430000 (0<0>) fixme:dbghelp:elf_new_wine_thunks Duplicate in comctl32<elf>: refDataPropName<004b4d60-00000020> subclasses<4b4d60-00000000> 0000001b:0000001c: loads DLL c:\windows\system\iphlpapi.dll @00b00000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\rpcrt4.dll @004e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\ole32.dll @006b0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shlwapi.dll @00d90000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shell32.dll @00550000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\lz32.dll @003e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\winex11.drv @00ca0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\imm32.dll @00710000 (0<0>) 0000001b:0000001c: exception code=0x80000003 wine-pthread: gdbproxy.c:1984: extract_packets: Assertion `i == gdbctx->out_len' failed. wine: Unhandled exception (thread 001d), starting debugger... WineDbg starting on pid 0x1e Unhandled exception: assertion failed in 32-bit code (0x595a97e2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:595a97e2 ESP:7fcbf38c EBP:7fcbf3a0 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00004e8c ECX:00004e8c EDX:00000006 ESI:00000000 EDI:2014fff4 Stack dump: 0x7fcbf38c: 200521f8 00004e8c 2014fff4 00000000 0x7fcbf39c: b7efe9e0 7fcbf4cc 20053948 00000006 0x7fcbf3ac: 7fcbf440 00000000 00000060 7d00bf80 0x7fcbf3bc: 00000068 00000000 2008bae7 7fcbf404 0x7fcbf3cc: 7d00bf88 7d00bfec 7fcbf4dc 2014fff4 0x7fcbf3dc: 00000059 0000005a 7fcbf4b0 20086515 0200: sel=1007 base=b7f04000 limit=00001f97 32-bit rw- Backtrace: =>1 0x595a97e2 (0x7fcbf3a0) 2 0x20053948 (0x7fcbf4cc) 3 0x2004b38e (0x7fcbf510) 4 0x75ff7e2f gdb_remote+0xaab(flags=0x1) [/home/skissane/osdevel/wine/programs/winedbg/gdbproxy.c:1981] in winedbg (0x7fcbfddc) 5 0x76002b9b main+0x473(argc=0x2, argv=0x7fee04a8) [/home/skissane/osdevel/wine/programs/winedbg/winedbg.c:1285] in winedbg (0x7fcbfeac) 6 0x75fef26f __wine_exe_main+0x176 in winedbg (0x7fcbff2c) 7 0x4bdbe9e2 start_process+0xb6(arg=0x0) [/home/skissane/osdevel/wine/dlls/kernel/process.c:996] in kernel32 (0x7fcbfff4) 8 0x20004935 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x595a97e2: ret Modules: Module Address Debug info Name (21 modules) ELF 0x0051b000-00537000 Deferred ld-linux.so.2 ELF 0x00539000-00663000 Deferred libc.so.6 ELF 0x00665000-00669000 Deferred libdl.so.2 ELF 0x0066b000-0068f000 Deferred libm.so.6 ELF 0x00a05000-00a17000 Deferred libpthread.so.0 ELF 0x20000000-20018000 DIA libwine.so.1 ELF 0x20154000-201c6000 Deferred ntdll<elf> \-PE 0x20170000-201c6000 \ ntdll ELF 0x201ea000-201f5000 Deferred libnss_files.so.2 ELF 0x201f5000-2020b000 Deferred psapi<elf> \-PE 0x20200000-2020b000 \ psapi ELF 0x39fc3000-39fff000 Deferred advapi32<elf> \-PE 0x39fd0000-39fff000 \ advapi32 ELF 0x45dc6000-45e01000 Deferred dbghelp<elf> \-PE 0x45dd0000-45e01000 \ dbghelp ELF 0x4bd54000-4be4f000 Stabs kernel32<elf> \-PE 0x4bd80000-4be4f000 \ kernel32 ELF 0x6be33000-6bf28000 Deferred libwine_unicode.so.1 ELF 0x75fd7000-76019000 Stabs winedbg<elf> \-PE 0x75fe0000-76019000 \ winedbg ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000001b 0000001c 0 0000001e (D) c:\windows\system\winedbg.exe 0000001d 0 <== 0000000e 0000000f 0 0000000a 0000000b 0 WineDbg terminated on pid 0x1e ===== gdb window ====== > gdb GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". (gdb) target remote localhost:32815 Remote debugging using localhost:32815 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target Malformed response to offset query, timeout (gdb)

2 1

More debugger quesions
by Robert Lunnon Sept. 4, 2005

Sept. 4, 2005

Well we are getting somewhere When my test application segfaults the debugger attaches and runs through a number of debug events eventually ariving at a segfault strace:winedbg:dbg_handle_debug_event 00000008:00000009: loads DLL c: \windows\system\imm32.dll @7f440000 (0<0>) trace:winedbg:dbg_handle_debug_event 00000008:00000009: exception code=80000003 Now I added some instrumentation and find the following happens IE trace:winedbg:dbg_handle_debug_event Continue on first exception is true trace:winedbg:dbg_handle_debug_event Breaking switch trace:winedbg:dbg_handle_debug_event Call ContinueDebugEvent trace:winedbg:dbg_handle_debug_event Continuing executio trace:winedbg:dbg_main_loop Wait for next debug event... In this code at the top of dbg_main_loop if (dbg_curr_process) dbg_printf("WineDbg starting on pid 0x%lx\n", dbg_curr_pid); /* wait for first exception */ while (WaitForDebugEvent(&de, INFINITE)) { WINE_TRACE("Calling handle_debug_event 2\n"); if (dbg_handle_debug_event(&de)) {WINE_TRACE("Event handled\n");break;} WINE_TRACE("Wait for next debug event...\n"); } Problem is that the client program is stopped, probably on a segfault trace because I enable tracing (stops) on all machine faults and signals when I attached it (this allows my replacement for wait4 to find out if a fault or signal happened in the debuggee). Everything deadlocks then since the debugger never continues the program after the exception (Or perhaps the wineserver never gets a message to restart it) Perhaps I don't understand the semantics of PTRACE wait4 interactions. Should I just let the app trap machine faults ? All help appreciated Bob

3 4

Re: wine/dlls/dinput joystick_linuxinput.c
by Marcelo Duarte Sept. 4, 2005

Sept. 4, 2005

Alexandre Julliard escreveu: >ChangeSet ID: 19966 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)winehq.org 2005/09/03 10:02:38 > >Modified files: > dlls/dinput : joystick_linuxinput.c > >Log message: > Daniel Remenak <dtremenak(a)gmail.com> > Implement EnumEffects, CreateEffect, EnumCreatedEffects, > SendForceFeedbackCommand, and GetForceFeedbackStatus for linux input > joysticks. > >Patch: http://cvs.winehq.org/patch.py?id=19966 > >Old revision New revision Changes Path > 1.25 1.26 +377 -12 wine/dlls/dinput/joystick_linuxinput.c > > I think that this patch is the cause of a compiler error in my box (Fedora core 2): make[2]: Entering directory `/home/mduarte/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: ** [joystick_linuxinput.o] Erro 1 make[2]: Leaving directory `/home/mduarte/wine/dlls/dinput' make[1]: ** [dinput/__install-lib__] Erro 2 make[1]: Leaving directory `/home/mduarte/wine/dlls' make: ** [dlls/__install-lib__] Erro 2

1 0

wined3d - d3d9 regression testing
by Oliver Stieber Sept. 3, 2005

Sept. 3, 2005

Hi, Wined3d in CVS is now in a reasonable state to start regression testing new changes against. I usually regression test against a few game demos and DirectX 9 tutorials, I'm going to list the DirectX 9 tutorials as they start to work (there are 68 tutorials that work with the big patch). The current list of working DirectX 9 demos is: from http://www.codesampler.com/dx9src.htm dx9_1pass_emboss_bump_mapping dx9_2pass_emboss_bump_mapping dx9_alpha_blending_texture dx9_multiple_vertex_buffers dx9_texture_dot3_blending dx9_texture_filtering dx9_texture_mipmapping dx9_texture_subloading dx9_tokamak_chain dx9_transforms dx9_vertex_data dx9_view_matrix dx9_view_ports dx9_spot_light dx9_texture dx9_texture_addressing (has a mipmapping error with ATI's drivers) dx9_primitive_types dx9_point_light dx9_dot3_bump_mapping dx9_effect_simple dx9_fonts dx9_indexed_geometry dx9_initialization dx9_lighting (has a slight artifact) dx9_material dx9_multitexture dx9_offscreen_rendering (faked) dx9_2d_demo_game (text for non-power2 textures, ship doesn't animate yet) from http://triplebuffer.devmaster.net/tutorials.php BumpMapping tb_dx9_03 tb_dx9_04 tb_dx9_05 (sort of) tb_dx9_06 tb_dx9_07 tb_dx9_08 tb_dx9_09 tb_dx9_10 from http://www.clootie.ru/delphi/download_dx90.html#Direct3D Tut01_CreateDevice Tut02_Vertices Tut03_Matrices Tut04_Lights Tut05_Textures Tut06_Meshes cull ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

5 12

wine20050830 - is quite fast
by Vijay Kiran Kamuju Sept. 3, 2005

Sept. 3, 2005

hi, previous it took 3-4 minutes to show the application in wine20050725, but the latest has reduced to less than a min. even in managed mode its faster. bye, Vijay

3 3

wine/ tools/winebuild/import.c dlls/winecrt0/M ...
by Stefan Leichter Sept. 3, 2005

Sept. 3, 2005

Hello, this patch http://cvs.winehq.org/patch.py?id=19957 broke the inital startup (creating of .wine directory) of wine for me. Wine crashes now with: wine: creating configuration directory '/home/sle/.wine'... wine-pthread: ne_module.c:203: __wine_dll_register_16: Assertion `i < 50' failed. wine: Unhandled exception (thread 0009), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x41603340 wine: wineprefixcreate failed while creating '/home/sle/.wine'. sle(a)sle3:/usr/src/wine/wine-20050902-0944> wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/system.reg : No such file or directory wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/ user.reg : No such file or directory on my system (SuSE 9.0) Bye Stefan

1 0

http://cvs.winehq.org/patch.py?id=19964
by Paul Vriens Sept. 3, 2005

Sept. 3, 2005

Hi, this latest change to the shellpath test produces the attached error on Windows XP. Haven't looked into this further. Cheers, Paul.

1 0

Opposite for wine_get_unix_filename()
by Phil Krylov Sept. 3, 2005

Sept. 3, 2005

Hi, What can I use as a function opposite to wine_get_unix_filename() (e.g. to pass a filename to GetSaveFileNameW() dialog)? -- Ph.

2 2

winebuld/winecrt changes and breakages
by Ivan Leo Puoti Sept. 3, 2005

Sept. 3, 2005

Your recent changes have broken the ntoskrnl build, because we're forced to link to kernel32 (that we don't need nor want) Could you please fix this? ntoskrnl is meant to be a native program anyway, so it shouldn't have an entry point routine like win32 progs. Being able to use NtProcessStartup instead of main would be an extra bonus. Of course this means we'll have to call NtProcessTerminate at shutdown but that's something all native progs on windows have to do too. Also I believe this patch of your to be wrong: http://cvs.winehq.org/patch.py?id=19957 The entry point of native drivers is DriverEntry, native drivers don't link to kernel32, thus can't call ExitProcess, also consider DriverEntry is like DllMain, it's an initialisation routine, the real work is then done by the DispatchDeviceControl function, so if you call ExitProcess nobody will have a chance to call the driver anyway. And all this is taken care by the io subsystem, so that entry point routine really shouldn't be there (Apart from the fact that windows doesn't have it). Ivan.

1 0

proper nt-style authentication (reactos, wine, samba tng)
by Luke Kenneth Casson Leighton Sept. 3, 2005

Sept. 3, 2005

[please note: due to its cross-discipline and cross-project nature, this message is going out to SEVERAL related project mailing lists. when replying, please take EXTRA caution not least because some of these lists are subscriber-only. also, please note: i _would_ post this also to the samba mailing lists but due to the fascist censorship in place since the 15th dec 2004, i am unable to do so. this is their decision and it is their loss. i am not asking you to respect that decision i am simply making you aware of it.] hi, out the woodwork i pop - not necessarily ready to chew anything because i know just how much work's involved, but what i did want to do was say "hi, i'm still here" and do a brain-dump of how authentication ideally needs to be implemented in reactos. at 2,600 words and 16k, this message is quite long and so i have placed a copy at http://lkcl.net/software/reports/reactos-auth.txt, just in case it doesn't make it past various mailing-list limits (i'll find out in a couple of minutes... :) it breaks down into a number of sections: 1) i describe the timescales and ways to cut them, along with some warnings and stuff. 2) amonst other stuff i outline some background as to why i am posting this to so many lists. 3) i outline a project plan and the dependencies and "optional" steps, 4) i describe a recommended implementation roadmap starting with the "minimum" requirements, and expand on some technical info and references i found, which would help with some of the "nice-to-have" steps. so. first. please do not be scared by how much work is involved, and how much code there is. it all hinges one ONE function and that one function... you are _not_ going to believe how much code that one function drags in, kicking and screaming, behind it. please also please i beg you DO NOT consider going "bleedin 'ellfire, that's so much frakkin work we can't POSSIBLY do it the way you describe, we MUST do it our own way, starting with what we know, love and have already started tackling, and can't possibly back out of what we've already done". should you choose to exercise the "NIH" option, i frakkin guarantee you that you will waste about five to eight years of your (collective) lives reinventing the wheel. "The Plan" outlined here will shave that down to about 12 to 18 months, utilising some SIX HUNDRED THOUSAND lines of pre-existing code, and later in this message i also outline a prioritisation of the necessary work to "cut down" the time to maybe about ... mmm... three or so months, by leaving out some of the "nice-to-have" stuff. actually... _all_ of the nice-to-have stuff :) that will at least "GetItWorking(tm)" and the rest of the bits can be considered at leisure once people go "god that's awful, we can't possibly leave it like that" and hopefully hopefully things will actually progress from there. remember - please: this stuff is sufficiently complicated such that you really can't afford the niceties such as "It Must Be Perfect (tm)" before it can be accepted. i've seen that shit before, and it's a baad mxxxxxxxer path to go down, especially with such complex and heavily interdependant reverse-engineering projects as reactos, wine, samba and freedce. anyway. fyi - before i begin, i should mention a couple of things: 1) this message also goes out the the apache devel mailing list (specifically the APR one) because the NT style authentication thing is the sort of thing that really _should_ be in a (special?) APR util library, along with "NT Named Pipes" - see http://en.wikipedia.org/wiki/NamedPipes one of the reasons why NT-style NamedPipes is _not_ in an APR util is because it is believed that NT-style NamedPipes do not fit the "least common denominator". by having the infrastructure outlined below, it is possible to move things "up one level" to the point where unix _has_ that denominononmination. also, if APR still has support for that god-awful program-running program called Win95, it would, with not much extra effort, be possible to port some reactos components to Win95 (!) such that ThePlan outlined here would make Win95 have proper NT-style authentication (!) now there's a horrible thought that will give MS and free software people nightmares both: upgrading Win95 by installing free software components at it. muhahahahah ahem. 2) i have filled in a number of pages on wikipedia.org. see http://en.wikipedia.org/wiki/User:lkcl. please take the time to review these pages, PLEASE help me with my totally biased "POV" (point-of-view) comments, by either editing the pages direct or by adding comments on the "talk" pages as appropriate. or alternatively dumping me in the nearest pond if ever you meet me. wikipedia is supposed to be encyclopedia-ic and some of my comments are anything but that. help!!! 3) please due to the quite broad distribution of this message across multiple mailing lists, please do NOT ask stupid questions like "what the hell do we need to use samba tng for, why can't we use samba in reactos"? and "why is this guy bothering us with this insane stuff?" and "how do i use killfiles?" or terry pratchett's - more specifically the librarian's favourite - "where has all the pie and custard gone?" please do your research: see if nothing else http://en.wikipedia.org/wiki/Samba_TNG_software and then start googling. anyway. onward. roughly in order of dependence, with "nice-to-have" status added as well: 1) port FreeDCE to Win32 - more specifically add in autoconf support for an alternative threading model - the one in reactos. no, this is not a joke: MSRPC is a critical part of NT infrastructure it's just that very few people are actually aware of this (including the US DoJ and the EU commission...) see http://www.google.co.uk/search?q=lkcl+wine+freedce for discussion links as to why - it's a long story and it took me several dozen messages spanning over many days to outline it in sufficient detail for it to be understood (mostly me getting things straight in my head...) status: "nice to have" but you will soon wish that you _did_ have it!!! there is also an opportunity to support Wine, here: essentially it's the same job, for DCOM, for proper "authentication" purposes in Wine just like in ReactOS... it's a long story. 2) remove dependence on "unix" security model from Samba TNG's services starting with samrd (perhaps by finishing off samrtdbd?) status: "essential". sub-projects: a) in Samba TNG, rework winbindd such that it is a REQUIRED service, and it has "modes" that, instead of "inventing" links between unix uids and nt sids, it reads smbpasswd and correlates unix uids with nt sids _just_ like is done now - but hard-coded through the awful code that has had to dieee since... about two weeks after i wrote it, back in 1999. this one's a long story but it's not actually required for reactos but _might_ be required for wine... status: "pretty much essential" but not for reactos but for making life easy to share tng development between reactos and unix. b) in Samba TNG, make the authentication code (smb-side and rpc server back-end-wise) contact winbindd BUT ONLY for resolving unix uids and unix gids - which is actually a VERY small task involving a few hundred lines of code. this goes back to the "SURS" stuff i wrote up in 1999 - but instead of a library it hands off the responsibility for sid<->uid+gid lookups to winbindd. it _may_ also be essential for Wine to operate correctly with authentication (which is a "stub" at the moment just like it is in reactos), to interoperate with other programs, to cache login credentials in order to do smb client-side operations, that sort of thing, under which circumstances, it will be necessary for Wine to have the same sort of thing. it's no big deal :) status: same as for 2a). c) in Samba TNG, abandon all use of hard-coded MSRPC stuff and utilise FreeDCE instead, and do a rewrite of all services, one by one (and because samba tng is modular, this _can_ be done one-by-one, checking MSRPC interoperability along the way between the "old" services, the "new" services, and also with NT itself). in and of itself, this critically depends on making DCEThreads reliable, though, or adding support (finally!) for POSIX threads. status: "non-essential" but you would soon end up wishing that you had :) 3) complete LsaLogonUser, add LsaLogonUserEx, in NTOSKRNL.DLL, and friends. my favourites. the LSASS stuff. these functions are quite simple: they are "redirectors" - a vector table of functions is required to be passed in, which includes things like "authenticate with my lovely service" and "free some memory". there are many LSASS sub-services: one of them is Netware, one of them is MSV1_0.DLL, one of them is Kerberos. there are others. LSASS is based on _exactly_ the same technique that dlopen does e.g in libdvdcss, and in freedce's ntlmsspauth.so, and in... mmm... the freedce transport module infrastructure and _many_ other projects ... except of course it's NT-based table of higher-order-functions not unix "dlopen()" ones. i'll stop trying to teach people to suck eggs, now *embarrassed* :) status: "essential". sub-projects: a) write an MSV1_0.DLL which registers with the LSASS service. this will utilise MSRPC functions that call into the Samba TNG "NETLOGON" service. there already exists "basic" functions inside Samba TNG that... well... it's a bit messy, but they work. the key function to be calling is cli_nt_login_interactive, and you will notice _very_ quickly from the arguments hey, some of those look... kinda... familiar!! see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/rpc_client/cli_… status: "essential." the "porting" bit of this code to FreeDCE i would classify as "non-essential" but again, you will soon wish that you _were_ using FreeDCE. that's basically it: there are other sub-projects such as turning the "Registry" code in ReactOS (or Wine) into an MSRPC service (yes, i did say pretty much everything that's anything critical in NT is an MSRPC service, didn't i? :) but they aren't "essential". i say basically it, but that ONE stupid function, cli_nt_login_interactive, drags in quite literally HALF A MILLION lines of code - 250,000 lines of it in FreeDCE, alone (which, like i said, could possibly be avoided but the hard-coded MSRPC stuff in samba tng is sufficiently awkward to make a rewrite utilising FreeDCE very attractive). what i would suggest is the following: 1) write an MSV1_0.DLL "test stub" in combination with completing the LSASS functions, which supports a username "test", domain of "test" and password of "test". code up a hard-coded "blob" - a NET_USER_INFO_3 structure - that contains the response / essential information of groups, gids, sids, user session key etc. see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_net… (note: i _did_ say it would be nice to utilise FreeDCE didn't i? well, the NET_USER_INFO_3 structure in that header file is a "messy" version that i recreated from off-the-wire back in about ... mmmm... 1997. there _do_ exist IDL-generated versions of this data structure, thanks to matthew chapman - NETLOGON.idl for example). once that works... 2) write a lovely insecure method of "outsourcing" the username, domain and password to an external server - Samba TNG - which performs the authentication on your behalf and gets back "real" data. this could be done simply with a TCP connection, throw the data in-the-clear over to a simple temporary shim service blah blah, bob's your uncle. 3) port samba tng's netlogond, samrd and lsarpcd to ReactOS. this is quite straightforward: about the only really essential "missing" bit is to tie the services in to "NT Named Pipes" rather than unix domain sockets. _but_ - they only need to be plugged in to a back-end transport which all services - any of samba tng's MSRPC services - would use. so there's a key bit of work needed - probably under 400 lines of code - and the rest should fall into place. this is where it would be SO much easier to be utilising FreeDCE. all that's needed would be to write a FreeDCE "transport" plugin for ReactOS - ncacn_np - and then you'd be DONE. it's a long story... hey, has someone implemented TransactNamedPipe() and CreateNamedPipe() in ReactOS? if not, it's quite straightforward to do, and it involves dropping opaque data blobs onto smbd (again, smbd ported to reactos...) i _did_ say it's a long story, didn't i? :) 4) finally: track down how "LsaLogonUserEx" works. LsaLogonUser utilises cleartext passwords. LsaLogonUserEx i BELIEVE utilises NT and LM password hashes, or some brain-dead encrypted variant thereof. once 1) is completed, then TA-DAAAAA!!! lib/secur/lsa.c's "LsaLogonUser" function actually gets REAL DATA! okay. notes: 1) regarding FreeDCE. see http://en.wikipedia.org/wiki/FreeDCE freedce is an interoperable version of MSRPC that is derived from EXACTLY the same source code (DCE 1.0 reference implementation) that is present in Windows NT. DCE/RPC was co-opted / adopted / borg-ified by microsoft to form the basis of NT domains because paul leach, a co-founder of apollo computers and originator of NCS which became DCE/RPC, ended up working for microsoft back at the time when dave cutler was doing the original NT 3.1. using FreeDCE is non-essential for small projects of less than about 8,000 lines of code. Samba TNG's MSRPC code comprises OVER ONE HUNDRED THOUSAND lines of code. that i carried on hand-crafting MSRPC packets for three years simply demonstrates quite how bloody stupid i am. that you - the wine team - continue to reinvent an non-interoperable version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY, demonstrates quite how just as bloody stupid you are being. that _can_ be taken as a compliment, as i genuinely i mean it with the greatest of respect. 2) regarding a strategy to "minimise" the amount of time needed to "Get Things Working". a) utilise samba tng as-it-is, porting it as-is to ReactOS (mingw32) b) utilise cli_nt_login_interactive() as-it-is. c) complete MSV1_0.DLL. this will be SUFFICIENT and would only take a few months. enhancements come later, roughly in this order: a) complete a port of FreeDCE to ReactOS, by beating DCEthreads to death and replacing it with Win32 (NT) threads - #ifdef style, autoconf style. b) locate NETLOGON.idl, samr.idl and lsarpc.idl from matthew chapman's stuff, or from "todd sabin's" http://razor.bindview.com, or from the samba web site. actually... see: http://www.bindview.com/services/razor/utilities/ compile up CLIENT-SIDE ONLY, using dceidl, and create a library for use inside MSV1_0.DLL. i know todd developed interoperable versions of these idl files, because he was using them, compiled with MIDL.EXE, to do security tests against NT 4.0. remember: these IDL files are what microsoft DOESN'T want anyone to have, and there are very good _legitimate_ reasons for it: they are "behind-the-scenes" APIs which, if some idiot inside microsoft went and wrote a tool which became publicly used and relied on, they would be stuffed: they have ENOUGH apis which date back 15 years and they don't need any more. that having been said, i hate the fact that they are forcing people to pay $50k up-front and then $100 per-client for frakkin _information_. bastards. c) replace cli_nt_login_interactive() with a function that utilises the above library that utilises netlogon, samr and lsarpc client-side stuff from b) above. basically, what it boils down to is that the functions inside cli_nt_login_interactive i wrote BY HAND after examining MSRPC traffic. those functions neeeed too dieeee and they can easily be replaced one-by-one with the "proper" versions from doing "dceidl -client lsarpc.idl". it takes a couple of seconds and you get a header file lsarpc.h and a lsarpc.o and you're DONE. question. why did i spend so long doing hand-marshalling of the nt domains code. perhaps because i would not be able to give microsoft absolute hell for three frakkin years? d) consider porting, one-by-one, the Samba TNG services lsarpcd, netlogond and samrd (or better samrtdbd) to FreeDCE runtime infrastructure. this is NOT essential but it is very worthwhile. every project needs to do at least two throw-aways and with the samba tng code, there has been approximately one and a half throwaways so far... time for a major one, ESPECIALLY in light of the reactos project. FINALLY: e) consider writing that winregd service but actually picking up REAL registry hive files. someone did write a "reader" of registry files, i do not recall who it was. [note: YESSSS!!! yeeeeeehawww, todd i could KISS you!!] http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/ntreg_readme.cfm todd wrote a registry-hive-reader as a linux filesystem driver!!!!! todd, you are bloody mad. *smooch*. f) consider writing a samr service with the FreeDCE runtime that utilises "registry" functions RegXXXX - _properly_. anyway, if you got this far: congratulations and welcome to a brief nightmare history of the development behind NT Domains Authentication. all of the infrastructure above _already_ exists - in Samba TNG. it's just... it works. it's a bit creaky at the edges, but it works. how about it? l. p.s. it almost goes without saying, but i will hint at it once again: you will not find the samba team's goals and strategic direction to be compatible with reactos. as a team, they lack the insight, vision and project management skills to be able to cope with such inter-dependant insane gibberish. this i say with much sadness because they are highly respected individuals in the free software community, and yet they are taking the samba project in very different - and ultimately time-consuming - directions from what is really really needed. due to pride they cannot admit this in public but they have been known to admit it in private. much much disappointment and sadness and there's absolutely nothing i can do about it. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

4 6

Re: Wine test results problem
by Juan Lang Sept. 2, 2005

Sept. 2, 2005

Hi Katerina, > I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. > > Why the number of tests executed and number of failures are so > different for the identical test groups? There are bugs in the tests, unfortunately. For example, these failures: > -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. > +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. There's a bug in that test, it succeeds the first time run on Windows, but fails subsequently because it attempts to delete a non-empty directory. (That's my fault, I wrote that test.) > How should I fix this to obtain stable results? Report the failing tests here. It would help if you could report the actual failures, not just the number of failures. Then keep bugging us till someone fixes them (or, submit patches that fix the tests ;) ) Cheers, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Strange problem with OpenGL in recent versions of wine
by Daniel Sept. 2, 2005

Sept. 2, 2005

Hi there, recent versions of wine have shown a very peculiar behaviour for me. The first I noticed it with was 20050628, whereas I know 20050310 to work in this respect. What happens is that any program that uses D3D or OpenGL will at startup complain that it is missing hardware acceleration, that I should change the color depth or some such thing. The program will then quit or switch to software rendering. Wine will at the same time show an OpenGL-related error. The exact error will differ from program to program, but it will always say the same: No Pixelformat matching what the program wanted could be found. Programs with which I have experienced this: Half-Life Unreal Quake 3 Demo Cube Hitman I seem to be the only one having this problem, as I couldn't find anything on the web. Is there something obvious I am missing? (Yes, Linux Q3 works fine) I would really appreciate any help with this, as I'm out of things to try. Feel free to ask for additional info, logfiles etc. regards, Daniel Skorka

1 0

Re: include/guiddef.h: C++ compatibility patch (with MSVC++ support)
by Dmitry Timoshkov Sept. 2, 2005

Sept. 2, 2005

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > --- include/guiddef.h (revision 26053) > +++ include/guiddef.h (local) > @@ -35,12 +35,18 @@ > #undef DEFINE_GUID > > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + EXTERN_C const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > - extern const GUID name > + EXTERN_C const GUID name > #endif > > #define DEFINE_OLEGUID(name, l, w1, w2) \ There are 2 problems with this patch: you forgot to provide a definition for EXTERN_C, and it needlessly duplicates code for the __cplusplus case. -- Dmitry.

2 1

Re: URLMON: Added CreateAsyncBindCtxEx implementation
by Robert Shearman Sept. 2, 2005

Sept. 2, 2005

Jacek Caban wrote: >+static void test_CreateAsyncBindCtxEx(void) >+{ >+ IBindCtx *bctx = NULL, *bctx_arg = NULL; >+ IBindStatusCallback *bsc = statusclb_create(); >+ BIND_OPTS bindopts; >+ HRESULT hres; >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, NULL, 0); >+ ok(hres == E_INVALIDARG, "CreateAsyncBindCtx failed: %08lx, expected E_INVALIDARG\n", hres); >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, > > Are you sure you mean to assign the value instead of just testing it? >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); >+ ok(bindopts.dwTickCountDeadline == 0, >+ "bindopts.dwTickCountDeadline = %08lx, expected: 0\n", bindopts.dwTickCountDeadline); >+ >+ IBindCtx_Release(bctx); >+ } >+ >+ CreateBindCtx(0, &bctx_arg); >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); > > Same here. -- Rob Shearman

1 0

Wine test results problem
by Katerina Nizhnik Sept. 2, 2005

Sept. 2, 2005

Hi, I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. I tried to use both pre-compiled binary from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe and Wine sources built by myself with Visual Studio .NET 2003 (20050830 version). What I do is just launching the test several times on the same machine and comparing log files received. Please, see the sample diff of 2 such log files. Why the number of tests executed and number of failures are so different for the identical test groups? It seems to be some synchronization problem. How should I fix this to obtain stable results? Thank you in advance. ------------------------------------------------------------ @@ -50,7 +50,7 @@ module: 34 tests executed, 0 marked as todo, 0 failures. mailslot: 75 tests executed, 0 marked as todo, 0 failures. path: 1741 tests executed, 0 marked as todo, 0 failures. -pipe: 419 tests executed, 0 marked as todo, 0 failures. +pipe: 418 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. @@ -78,7 +78,7 @@ util: 139 tests executed, 0 marked as todo, 136 failures. mlang: 11211 tests executed, 0 marked as todo, 20 failures. msacm: 385 tests executed, 0 marked as todo, 0 failures. -profile: 127 tests executed, 0 marked as todo, 1 failure. +profile: 127 tests executed, 0 marked as todo, 0 failures. htmldoc: 688 tests executed, 0 marked as todo, 0 failures. protocol: 255 tests executed, 0 marked as todo, 0 failures. db: 73 tests executed, 0 marked as todo, 0 failures. @@ -104,7 +104,7 @@ env: 611 tests executed, 0 marked as todo, 0 failures. error: 813 tests executed, 0 marked as todo, 0 failures. generated: 1981 tests executed, 0 marked as todo, 0 failures. -info: 765 tests executed, 0 marked as todo, 0 failures. +info: 725 tests executed, 0 marked as todo, 0 failures. large_int: 700 tests executed, 0 marked as todo, 0 failures. path: 230 tests executed, 0 marked as todo, 5 failures. reg: 9 tests executed, 0 marked as todo, 0 failures. @@ -133,7 +133,7 @@ main: 15 tests executed, 0 marked as todo, 1 failure. generated: 1141 tests executed, 0 marked as todo, 0 failures. shelllink: 116 tests executed, 0 marked as todo, 3 failures. -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. tests/shellpath.c: 4 tests executed, 0 marked as todo, 0 failures. shellpath: 447 tests executed, 0 marked as todo, 3 failures. shlexec: 20 tests executed, 0 marked as todo, 0 failures. @@ -174,4 +174,4 @@ timer: 44 tests executed, 0 marked as todo, 0 failures. wave: 289 tests executed, 0 marked as todo, 15 failures. protocol: 26 tests executed, 0 marked as todo, 0 failures. -sock: 8971 tests executed, 0 marked as todo, 5 failures. +sock: 8951 tests executed, 0 marked as todo, 5 failures. ------------------------------------------------------------ -- Sincerely yours, katy

1 0

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
by Alex Villacís Lasso Sept. 1, 2005

Sept. 1, 2005

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> Robert Reif wrote: >> >>> Fix the wine ALSA driver rather than the test unless you can prove >>> that the test fails on Windows. >>> > Hers is a real quick hack that fixes the problem. This should give > you someplace to start. > >------------------------------------------------------------------------ > >? audio.c.test >? audio.diff >Index: audio.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v >retrieving revision 1.96 >diff -p -u -r1.96 audio.c >--- audio.c 12 Aug 2005 11:17:54 -0000 1.96 >+++ audio.c 31 Aug 2005 00:59:33 -0000 >@@ -2527,14 +2527,16 @@ static DWORD wodOpen(WORD wDevID, LPWAVE > getFormat(wwo->format.Format.wFormatTag)); > > dir=0; >- EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+// EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+ buffer_size = 0x10000; >+ EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_size_near(pcm, hw_params, &buffer_size), MMSYSERR_INVALPARAM, "unable to set buffer size"); > dir=0; > EXIT_ON_ERROR( snd_pcm_hw_params_set_period_time_near(pcm, hw_params, &period_time, &dir), MMSYSERR_INVALPARAM, "unable to set period time"); > > EXIT_ON_ERROR( snd_pcm_hw_params(pcm, hw_params), MMSYSERR_INVALPARAM, "unable to set hw params for playback"); > > err = snd_pcm_hw_params_get_period_size(hw_params, &period_size, &dir); >- err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); >+// err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); > > snd_pcm_sw_params_current(pcm, sw_params); > EXIT_ON_ERROR( snd_pcm_sw_params_set_start_threshold(pcm, sw_params, dwFlags & WAVE_DIRECTSOUND ? INT_MAX : 1 ), MMSYSERR_ERROR, "unable to set start threshold"); > > From what I could see from the patch, it tries to set a buffer size instead of a buffer time. However, the patch did not solve the problems as it is. First, the patch supplies a constant value for snd_pcm_hw_params_set_buffer_size_near(). However, the ALSA documentation states that the parameter for buffer_size for this function is given in *frames*, not bytes. Since a frame (nChannels * bitsPerSample / 8) can be from 1 to 4 bytes depending on the requested format, this patch only fixes the frame length, not the byte length. So the attached patch divides the required buffer size (in bytes) by the frame size to arrive to the buffer size in frames. Second, even after the division, the ALSA API is unable to honor the exact value required (at least in my hardware). For most formats the upper limit on the byte size is 30104 bytes, but for the reference tone it changes to 15052 bytes. So it triggers the buffer resize all over again. The attached patch hardcodes the value of 15052 bytes (0x3acc) as the required buffer size, and then the ALSA API doesn't resize the buffer. But obviously, this is a machine-dependent value that might be different in everybody else's machine. Any other value greater than 15052 triggers the buffer resize, and other values below it cause awful buzzings and silences on the games I have tested. Even the chosen value of 15052 bytes, though it works in the tested games, causes buzzings instead of the proper tone on some 8000Hz and 11050Hz tests (the tests where the playtime is around 100-300 ms instead of 1000 ms in the attached trace). Third (but this is no longer a winealsa issue), I still get the critical section timeouts on invalid threads in aprox. 1 in 5 runs of the interactive dsound test, even on an idle CPU. This proves that the timeout bug is not because of CPU load, and should be investigated further. All of this leads me to think that the winealsa driver should give up on trying to provide access to the direct mmap buffer, and revert to providing a fixed-size buffer that is then used to feed the actual ALSA buffer. This would a) hide the buffer resizes from the tests and the games, and b) remove the need of the undocumented hardware pointer function. In fact, I do not remember what was the rationale behind switching from the old model to the current one. In addition, I have tested a few games Any comments on this are welcome. Alex Villacís Lasso

2 1

curses problems in wineconsole
by Robert Lunnon Sept. 1, 2005

Sept. 1, 2005

curses.c in wineconsole seems to be under (re) development at the moment. Under Solaris I get the following. I presume this is because the changes are being developed with ncurses in mind. gmake gcc -c -I. -I. -I../../include -I../../include -DUNICODE -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I /opt/sfw/cups/include -I /opt/sfw/cups/include -o curses.o curses.c In file included from winecon_private.h:24, from curses.c:50: ../../include/wincon.h:133:1: warning: "MOUSE_MOVED" redefined In file included from curses.c:41: /usr/include/curses.h:1487:1: warning: this is the location of the previous definition curses.c:70: error: parse error before "mmask_t" curses.c:70: warning: no semicolon at end of struct or union curses.c:75: error: parse error before '}' token curses.c:95: error: `mouseinterval' undeclared here (not in a function) curses.c:95: warning: type defaults to `int' in declaration of `p_mouseinterval' curses.c:96: error: `mousemask' undeclared here (not in a function) curses.c:96: warning: type defaults to `int' in declaration of `p_mousemask' curses.c: In function `WCCURSES_ResizeScreenBuffer': curses.c:221: error: dereferencing pointer to incomplete type curses.c:221: error: dereferencing pointer to incomplete type curses.c:222: error: dereferencing pointer to incomplete type curses.c:223: error: dereferencing pointer to incomplete type curses.c:225: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:229: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_PosCursor': curses.c:250: error: dereferencing pointer to incomplete type curses.c:257: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_ComputePositions': curses.c:299: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_Refresh': curses.c:354: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_FillMouse': curses.c:557: error: `MEVENT' undeclared (first use in this function) curses.c:557: error: (Each undeclared identifier is reported only once curses.c:557: error: for each function it appears in.) curses.c:557: error: parse error before "mevt" curses.c:559: error: `mevt' undeclared (first use in this function) curses.c:559: error: too many arguments to function curses.c:586: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:588: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:590: error: `BUTTON_ALT' undeclared (first use in this function) curses.c: In function `WCCURSES_FillCode': curses.c:657: error: dereferencing pointer to incomplete type curses.c:746: error: `KEY_RESIZE' undeclared (first use in this function) curses.c: In function `WCCURSES_GetEvents': curses.c:830: error: `KEY_CODE_YES' undeclared (first use in this function) curses.c: In function `WCCURSES_DeleteBackend': curses.c:849: error: `mmask_t' undeclared (first use in this function) curses.c:849: error: parse error before "mm" curses.c:853: error: dereferencing pointer to incomplete type curses.c:855: error: dereferencing pointer to incomplete type curses.c:856: error: dereferencing pointer to incomplete type curses.c:856: error: `mm' undeclared (first use in this function) curses.c:856: error: called object is not a function curses.c:859: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_MainLoop': curses.c:873: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_InitBackend': curses.c:906: error: invalid application of `sizeof' to incomplete type `inner_data_curse' curses.c:921: error: dereferencing pointer to incomplete type curses.c:956: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:956: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:956: error: `BUTTON_ALT' undeclared (first use in this function) curses.c:957: error: dereferencing pointer to incomplete type curses.c:957: error: called object is not a function curses.c:962: error: called object is not a function curses.c:966: error: dereferencing pointer to incomplete type curses.c:966: error: called object is not a function gmake: *** [curses.o] Error 1

2 2

Re: Web Server Back Online
by Jeremy Newman Sept. 1, 2005

Sept. 1, 2005

Try that, let me know if it's better. Note: web browses cache mime type as well, so try a different .bin if needed. I'll try it for now. I played with mod_mime_magic as well, but was unable to get any joy out of it. It is supposed to do what the command 'file' does and get the mime type based on the contents of the file. Didn't seem to work though. On Thu, 2005-09-01 at 10:49 -0500, Robert Shearman wrote: > Could you configure .bin files to have a MIME type of text/x-diff or > something in Apache? Maybe just for the mailman directory if there are > other .bin files on the web site. >

1 0

uxtheme requiring shlwapi
by Aric Stewart Sept. 1, 2005

Sept. 1, 2005

Thanks for the great work on this! It is really cool, however I am having a dependency problem that would be great to resolve. uxtheme currently links in shlwapi.dll, shlwapi.dll in turn links in ole32.dll. Since WM_NCCREATE seems to load uxtheme it would be that ole32 is being loaded almost all the time now. This is an issue because when we here at CodeWeavers try to install dcom95.exe we need to set ole32=native (ie, disabled) so that dcom95 does not detect the builtin version. However because uxtheme is now being loaded with MessageBoxA, the install fails because it is unable to load ole32, thus shlwapi and thus uxtheme. Looking at uxtheme it seems like there are only 3 functions being used out of shlwapi. StrChrW: this is also located in comctl32.dll, while i hate to add comctl32.dll as a dependency to swap out shlwapi, it does solve the current problem, also a quick reimplementation of StrChrW as a helper function would remove this problem totally. SHRegGetPathW and PathAddBackslashW: These are really convenient functions but should not be hard to make little helper functions to replace the dependency. Any chance these changes could be made? Thanks alot, -aric

2 2

Re: KERNEL: check for NULL in LoadModule16
by Andreas Mohr Sept. 1, 2005

Sept. 1, 2005

Hi, On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > An old copy of Print Shop Deluxe Companion manages to supply a NULL as a > name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This > patch adds a check to return ERROR_READ_FAULT instead of crashing. > > Alex Villacís Lasso > > Changelog: > * Add a NULL check in LoadModule16 Are you sure that Windows does that thing? Somehow I really cannot imagine that during all these years this one has gone unnoticed... (and is ERROR_READ_FAULT the correct error to return here?) Thanks, Andreas Mohr

3 5

Re: Wine device drivers proposal
by Evgeny F Sept. 1, 2005

Sept. 1, 2005

In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny

4 8

Re: include/guiddef.h: C++ compatibility patch
by Dmitry Timoshkov Sept. 1, 2005

Sept. 1, 2005

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + extern const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > extern const GUID name PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach. -- Dmitry.

4 4