March 2005 - Wine-Devel - list.winehq.org

Re: Re: [DMUSIC/DINPUT] includes fixes
by fenix＠club-internet.fr March 14, 2005

March 14, 2005

4 4

Automatic installation rev-eng utility
by Shachar Shemesh March 14, 2005

March 14, 2005

Hi all, I said this in a reply in one of the threads (the one about Windows registry), and got zero reply. I'm bringing the subject up again here. Back in 1996 (and until around 2000) I was project manager for a project called "GTFormat". This was a project used by the late Packard Bell, as well as NEC in Japan, to put the programs bundled with the machines on the hard disks shipped out to customers. The tools consist of a tool that understands what the original installation did, a database to do offline conflict resolution and other stuff, and a front end to perform a (silent) installation of the result. I have written most of the code in the last part of this project, and as I said before, managed the entire thing. We also had a tool the generated files for the last part directly from the first part, without going through the database. Now, the tool was written when I was an employee of the company that produced them (G.Tek Technologies, today called gteko), but I believe that given enough persuasion I can get their approval to either freely distribute or actually open source the detection and the installation tool. I believe most of the distinguishing value of the tool as far as Gteko is concerned is in the database, which is not relevant for Wine in any way. The tool is written mostly in C++ for Visual Studio 6. It may require pulling out a single proprietary library (compression), but should not pose a problem (zlib does a wonderful job, after all). The question, therefor, is this. Should I try? The tool has proven itself over a long period of time, and is fairly reliable (at least was back at the time). It CAN solve some of our installer related problems. Your opinions are welcome. So, what say you? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

2 2

Re: make mlang_test.exe loadable on NT 4.0 [resend, 3nd time]
by Alexandre Julliard March 14, 2005

March 14, 2005

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hi Alexandre, > > you have now ignore this patch three times :-( is anything wrong with it? or > does "wine-patches" have a hole ? There must be a hole somewhere yes, it's the first time I ever see that patch. Maybe my spam filter doesn't like you <g> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [X11DRV] Fix X11 Device list leak
by Raphael March 14, 2005

March 14, 2005

Hi, > Thanks for submitting this patch. > These are exactly the fixes I was about to submit! Nothing :) > Your patch should should have a major impact on users of applications > which use the wintab library: They should all start to function to some > degree. i hope so, waiting for users report now :) > Apologies for not commenting on patch/ submitting a fix earlier.... > A major knee operation has put me out of action for the last few weeks. :( Have a good recovery > P.S. Please don't expect timely responses to mails for at least > another week. > I'll try my best to respond, but can't promise anything. > Regards, Raphael

1 0

Re: richedit patches by Phil Krylov
by Phil Krylov March 14, 2005

March 14, 2005

On Mon, 14 Mar 2005 19:31:25 +0100 Krzysztof Foltman <kfoltman(a)portal.onet.pl> wrote: > > ChangeLog: > > Initial implementation of EM_STREAMOUT and RTF writer. > > Nice to see this functionality implemented (I really didn't want to > implement it myself). Very good code too. Thanks. Thanks :) > The new function ME_FindItemAtOffset isn't really necessary, you can > achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should > have used it in ME_GetTextW instead of reimplementing the same > functionality). I'm going to get rid of it later. Oh sorry, I haven't noticed that it already exists. > Now when both EM_STREAMIN and EM_STREAMOUT work, I can start > implementing the rest of the clipboard code. The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. -- Ph.

1 0

Re: [patch] x86: fix ESP corruption CPU bug
by Stas Sergeev March 14, 2005

March 14, 2005

Hi, Linus Torvalds wrote: > Btw, Stas, one thing I'd really like to see is even a partial list of > anything that actually cares about this. Ie, if there is some known > Windows app where Wine works better or something like that, just adding I am not using Wine too much, but I've found this: http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/winedos/int31.c?rev=1.41&… --- /* due to a flaw in some CPUs (at least mine), it is best to mark stack segments as 32-bit if they can be used in 32-bit code. Otherwise, these CPUs may not set the high word of esp during a ring transition (from kernel code) to the 16-bit stack, and this causes trouble if executing 32-bit code using this stack. */ --- I added win-devel to CC, maybe people there can tell if that patch has any value for them or not. The reference to the original patch: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/1794.html Dosemu looks a little better on that, the whole chapter of the docs is dedicated to that problem: http://dosemu.sourceforge.net/docs/EMUfailure/t1.html#AEN55 There you can find a (relatively small) list of the programs that are affected, but I personally have the old Microsoft linker that crashes, and a few more DOS games. > Another way of saying the same thing: I absolutely hate seeing patches > that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS. > So I'd like to have a bit more of a case for this patch, since I know what > the case against it is ;) Yep, and the informational leak it closes, looks also rather minor. So it is only a matter of how do you care about the dosemu and the DOS games under linux. Considering the amount of the dosemu-related code in vm86.c, I guess you care:) And uhm, adding the list of the DOS games to the comments of the Linux kernel code, doesn't sound like a good idea to me:)

6 7

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Mike McCormack March 14, 2005

March 14, 2005

Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Would you be able to write a conformance test using what you've found, to make sure it doesn't break again? Even just posting the test program to wine-patches so somebody could create a conformance test out of it would be great... Mike

2 1

richedit patches by Phil Krylov
by Krzysztof Foltman March 14, 2005

March 14, 2005

> ChangeLog: > Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. IMHO the patch can be applied without changes. The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. > Added "generator" RTF destination handling. > Added missing PFA_JUSTIFY definition to richedit.h. Thanks for the fixes, I really didn't know how to get rid of the \generator. Maybe it will help me figure out how to ignore the rest of the RTF junk that I can't use anyway (\pgdsctbl and others). Krzysztof

3 3

Let's fix Steam!
by Scott Ritchie March 14, 2005

March 14, 2005

Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine. This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :) So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/ - however, I'm not sure if it's plausible to run a regression analysis since there are no patches available against the direct crossover version of Wine. At this point, I'm not even sure which file has broken, although I do know that it's one we've had problems with in the past based off of IRC conversations. If anyone could follow up with more info, particularly about the specifics of the error, I'm sure we'd all appreciate it greatly. Thanks, Scott Ritchie

3 11

Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
by Mike Hearn March 14, 2005

March 14, 2005

T.J. Zeeman wrote: >>>Warcraft still complains about the CD-rom being MIA though :( I'll see >>>if I can dig up a few hints from the log this weekend. >> >>Make sure your kernel hsa the ptrace regression fixes in. > > > I guess you meant the problems refered to in WWN250 > (http://www.winehq.com/?issue=250) I checked and the patch there is > only for i386. I ported those to the x86_64 files (see attachments) and > tried again to no avail. > > I also tried the test app as posted by Linus Torvalds here: > http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html > When trying that on amd64 with the ptrace patches it does not even want > to compile (not completely surprising). In the chroot it segfaults. > A strace showed the following: > > x5556c000 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0 > old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/lib/tls/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., > 512) = 512 > fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 > old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x55576000 > old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 3, 0x129000) = 0x5569f000 > old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| > MAP_ANONYMOUS, -1, 0) = 0x556a7000 > close(3) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x556aa000 > set_thread_area({entry_number:-1 -> 11, base_addr:0x556aa2a0, > limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, > limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > munmap(0x5556d000, 32850) = 0 > rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0 > mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > > > I haven't been this deep into low level code in a long time (and that > was 8086 asm simulated on a sparc), but I thought this would work and > not segfault. Anybody around here that can comment on that? Or should I > take this to another forum to further investigate? If so, where would > you suggest I take it? I'm not sure, probably lkml would be best but I'm not subscribed to that. I'll CC wine-devel and maybe somebody there can help. I'd recommend pinging Linus and asking about whether the ptrace regressions still affect x86-64. thanks -mike > regards, > Thomas > > > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/ptrace.c 2004-12-24 22:34:30.000000000 +0100 > +++ ptrace.c 2005-03-01 20:32:29.713639136 +0100 > @@ -79,6 +79,28 @@ > return 0; > } > > +static void set_singlestep(struct task_struct *child) > +{ > + long eflags; > + > + set_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG); > + child->ptrace |= PT_DTRACE; > +} > + > +static void clear_singlestep(struct task_struct *child) > +{ > + if (child->ptrace & PT_DTRACE) { > + long eflags; > + > + clear_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags & ~TRAP_FLAG); > + child->ptrace &= ~PT_DTRACE; > + } > +} > + > /* > * Called by kernel/ptrace.c when detaching.. > * > @@ -86,11 +108,12 @@ > */ > void ptrace_disable(struct task_struct *child) > { > - long tmp; > +/* long tmp; > > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + put_stack_long(child, EFL_OFFSET, tmp); */ > + clear_singlestep(child); > } > > static int putreg(struct task_struct *child, > @@ -338,8 +361,6 @@ > break; > case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */ > case PTRACE_CONT: { /* restart after signal. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > @@ -347,12 +368,9 @@ > set_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > else > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = data; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET); > - tmp &= ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET,tmp); > + clear_singlestep(child); > wake_up_process(child); > ret = 0; > break; > @@ -394,34 +412,23 @@ > * exit. > */ > case PTRACE_KILL: { > - long tmp; > - > ret = 0; > if (child->exit_state == EXIT_ZOMBIE) /* already dead */ > break; > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = SIGKILL; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + clear_singlestep(child); > wake_up_process(child); > break; > } > > case PTRACE_SINGLESTEP: { /* set the trap flag. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - if ((child->ptrace & PT_DTRACE) == 0) { > - /* Spurious delayed TF traps may occur */ > - child->ptrace |= PT_DTRACE; > - } > - tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > - set_tsk_thread_flag(child, TIF_SINGLESTEP); > + set_singlestep(child); > child->exit_code = data; > /* give it a chance to run. */ > wake_up_process(child); > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/signal.c 2004-12-24 22:35:23.000000000 +0100 > +++ signal.c 2005-03-01 20:33:11.425298000 +0100 > @@ -205,8 +205,14 @@ > err |= __put_user(me->thread.trap_no, &sc->trapno); > err |= __put_user(me->thread.error_code, &sc->err); > err |= __put_user(regs->rip, &sc->rip); > + > + /* > + * Iff TF was set because the program is being single-stepped by a > + * debugger, don't save that information on the signal stack.. We > + * don't want debugging to change state. > + */ > eflags = regs->eflags; > - if (current->ptrace & PT_PTRACED) { > + if (current->ptrace & PT_DTRACE) { > eflags &= ~TF_MASK; > } > err |= __put_user(eflags, &sc->eflags); > @@ -324,12 +330,16 @@ > regs->rsp = (unsigned long)frame; > > set_fs(USER_DS); > + /* > + * Clear TF when entering the signal handler, but > + * notify any tracer that was single-stepping it. > + * The tracer may want to single-step inside the > + * handler too. > + */ > if (regs->eflags & TF_MASK) { > - if ((current->ptrace & (PT_PTRACED | PT_DTRACE)) == (PT_PTRACED | PT_DTRACE)) { > + regs->eflags &= ~TF_MASK; > + if (current->ptrace & PT_DTRACE) > ptrace_notify(SIGTRAP); > - } else { > - regs->eflags &= ~TF_MASK; > - } > } > > #ifdef DEBUG_SIG

6 14

Re: STI, device drivers and stuff
by Steven Edwards March 14, 2005

March 14, 2005

Hi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > 2. STI has kernel mode components to deal USB / SCSI / > > serial / parallel ports. Is there any attempt to bring > > kernel mode support into Wine (ReactOS/Wine merger?) > > any time soon? If not, should I implement USB support > > using libusb in user-space? > > Wine is purely user-space, so yes, use libusb I guess. CrossOver is using libusb for the iPod stuff. There is little chance of sharing much of the hardware support with ReactOS however the higher level stuff is being shared such as setupapi. Having a wineserver thread or something that acts like the umpnpmgr on Windows would allow us to share a bit more code as well. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

DOS interrupts in Wine
by Sam Lauber March 14, 2005

March 14, 2005

Does Wine correctly implement all the DOS Services and interrupts? Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

3 2

Re: MSI: add property IDs for MSI summary information
by Juan Lang March 14, 2005

March 14, 2005

--- Mike McCormack <mike(a)codeweavers.com> wrote: > Yes, it's really in MsiDefs.h from the Windows Platform SDK. Weird. > As far as I can tell, MSI also reimplements the property set storage > code, as it makes no calls to the ole storage implementation of > IPropertySetStorage. Perhaps there is some subtle difference between > the two implementations? Or maybe they did that because > IPropertySetStorage isn't available on earlier OLE implemenations? More likely the former, though I wouldn't hazard a guess as to why. MS allows you to reimplement these, they just provide a default impl. It's been around for quite a while, though, the best description I've found is from 1993-1995, well before MSI: http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnarolegen… --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: MSI: add property IDs for MSI summary information
by Juan Lang March 14, 2005

March 14, 2005

Hi Mike, > +#define PID_DICTIONARY 0 > +#define PID_CODEPAGE 1 > +#define PID_TITLE 2 Is it really like this in the PSDK? Some of these are already defined in propidl.idl. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Zuma
by Juan Pablo Sousa March 14, 2005

March 14, 2005

Hi, I'm trying to make the game Zuma work you can get the demo from: http://www.popcap.com/launchpage.php?theGame=zuma i've tried setting version to both win98 and winxp, in both cases I get very similar results I don't know where to start, the last line gives me the idea it's even chrashing the debugger, any ideas? here are the last lines running with +relay: 0009:Ret ntdll.RtlAcquirePebLock() retval=00000000 ret=77b18896 0009:Call ntdll.RtlUnicodeStringToAnsiString(7792fa0c,77eff920,00000001) ret=77b188bd 0009:Ret ntdll.RtlUnicodeStringToAnsiString() retval=00000000 ret=77b188bd 0009:Call ntdll.RtlReleasePebLock() ret=77b188d4 0009:Ret ntdll.RtlReleasePebLock() retval=00000000 ret=77b188d4 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.NtCreateEvent(77bf0974,001f0003,00000000,00000001,00000000) ret=77b5ffb7 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=77b5ffb7 0009:Ret PE DLL (proc=0x77afdef0,module=0x77af0000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0009:Ret ntdll.LdrInitializeThunk() retval=00000000 ret=77b44b6b 0009:Call ntdll.RtlImageNtHeader(00400000) ret=77b44b79 0009:Ret ntdll.RtlImageNtHeader() retval=004000f8 ret=77b44b79 0009:Starting process L"C:\\Program Files\\PopCap Games\\Zuma Deluxe\\Zuma.exe" (entryproc=0x856000) wine_dbg_vprintf: debugstr buffer overflow (contents: '0009:Call kernel32.VxDCall0(0086e000,0000000a,00857cf4 "\x8b\\$\x0c\xeb\x03\xeb\xfc\xeb\xeb\x01\xeb\xff\x8b\xb0",7792ff38 L"\ffff\ffff\de98\77af\96b0\77b1\7928\77bc",00856030,77b44ba2,77eff6c0 "",00000009,77eff04c,00856000,ffffffff (invalid),77afde98 L"\25ff\f4e4\77bc\f689\25ff\f4e8\77bc\f689\25ff\f4ec\77bc\f689\25ff\f4f0\77bc\f689\25ff\f4f4\77bc\f689\25ff\f4f8\77bc\f689\25ff\f4fc\77bc\f689\25ff\f500\77bc\f689\25ff\f504\77bc\f689\25ff\f508\77bc\f689\25ff\f50c\77bc\f689\8955\53e5\ec83\e814\81d8\fffe\c381\9a2c\000c\7d83\010c\3175\bb83\6e5c\0001\7501\8b28"...,77b196b0,77bc7928,00000000,00000000,7792fff4,7792ff28,77b44b1a,00000001,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,77bc7928,00000000,00000000,00000000,b7fb6dd1,00000000,Exception frame is not in st') err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception.

1 0

[advpack] Implement RegisterOCX and stub out DelNodeRunDLL32
by Matthew Mastracci March 14, 2005

March 14, 2005

This patch helps the IE6 installer get past the DLL registration stage. The DelNodeRunDLL32 function is stubbed out, but RegisterOCX will correctly register a COM DLL by calling its DllRegisterServer function. ChangeLog: * dlls/advpack/advpack.c Matthew Mastracci <mmastrac(a)canada.com> Implement RegisterOCX Stub for DelNodeRunDLL32 Index: dlls/advpack/advpack.c =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.c,v retrieving revision 1.7 diff -u -r1.7 advpack.c --- dlls/advpack/advpack.c 20 Jan 2005 20:03:13 -0000 1.7 +++ dlls/advpack/advpack.c 14 Mar 2005 07:35:54 -0000 @@ -32,6 +32,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(advpack); +typedef HRESULT (*DLLREGISTER) (void); + /*********************************************************************** * DllMain (ADVPACK.@) @@ -172,3 +174,60 @@ return S_OK; } + +/*********************************************************************** + * RegisterOCX (ADVPACK.@) + */ +void WINAPI RegisterOCX( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + WCHAR wszBuff[MAX_PATH]; + WCHAR* pwcComma = &wszBuff[0]; + HMODULE hm; + DLLREGISTER pfnRegister; + HRESULT hr; + + TRACE("(%s)\n", cmdline); + + MultiByteToWideChar(CP_ACP, 0, cmdline, strlen(cmdline), wszBuff, MAX_PATH); + while (!(*pwcComma == ',' ) && *pwcComma) + { + pwcComma++; + } + *pwcComma = '\0'; + + TRACE("Parsed DLL name (%s)\n", debugstr_w(wszBuff)); + + hm = LoadLibraryExW(wszBuff, 0, LOAD_WITH_ALTERED_SEARCH_PATH); + if (!hm) + { + ERR("Couldn't load DLL: %s\n", debugstr_w(wszBuff)); + return; + } + + pfnRegister = (DLLREGISTER)GetProcAddress(hm, "DllRegisterServer"); + if (pfnRegister == NULL) + { + ERR("DllRegisterServer entry point not found\n"); + } + else + { + hr = pfnRegister(); + if (hr != S_OK) + { + ERR("DllRegisterServer entry point returned %08lx\n", hr); + } + } + + TRACE("Successfully registered OCX\n"); + + FreeLibrary(hm); +} + +/*********************************************************************** + * DelNodeRunDLL32 (ADVPACK.@) + */ +void WINAPI DelNodeRunDLL32( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + FIXME("(%s) FIXME: stub\n", cmdline); +} + Index: dlls/advpack/advpack.spec =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.spec,v retrieving revision 1.5 diff -u -r1.5 advpack.spec --- dlls/advpack/advpack.spec 20 Jan 2005 20:03:13 -0000 1.5 +++ dlls/advpack/advpack.spec 14 Mar 2005 07:35:54 -0000 @@ -2,7 +2,7 @@ @ stub AdvInstallFile @ stub CloseINFEngine @ stub DelNode -@ stub DelNodeRunDLL32 +@ stdcall DelNodeRunDLL32(ptr ptr str long) @ stdcall DllMain(long long ptr) @ stdcall DoInfInstall(ptr) @ stub ExecuteCab @@ -23,10 +23,11 @@ @ stub RegRestoreAll @ stub RegSaveRestore @ stub RegSaveRestoreOnINF -@ stub RegisterOCX +@ stdcall RegisterOCX(ptr ptr str long) @ stub RunSetupCommand @ stub SetPerUserSecValues @ stub TranslateInfString @ stub TranslateInfStringEx @ stub UserInstStubWrapper @ stub UserUnInstStubWrapper

2 3

Window style problem with Steam
by Stefan Dösinger March 14, 2005

March 14, 2005

Hello! I had a look at the "no keyboard problem" with Steam. A little reseach showed that Steam creates its main Window with WS_SYSMENU set but WS_CAPTION not set. MSDN says that WS_CAPTION must be set if WS_SYSMENU is used: WS_SYSMENU Creates a window that has a window menu on its title bar. The WS_CAPTION style must also be specified. (from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu…) If I check for this case in WIN_CreateWindowEx and set WS_CAPTION, the Window is controlled by KWM and I can type in the Steam window. But KWM draws the normal Window boarder and it overlaps the rest of the Window and confuses the mouse. Furthermore the menu of the systray applet has a Caption. The solution I've found is to set the WS_EX_APPWINDOW flag in cs->dwExStyle. In this case Steam behaves as I'd expect it. But is this a correct solution? Any suggestions? Stefan

1 0

Scrollkeeper, the documentation, XML, and the way forward
by Scott Ritchie March 14, 2005

March 14, 2005

I wanted the Wine documentation to appear on the nice help menus, like other standard apps. I learned that the way to do this is to write an OMF file for each document, which scrollkeeper can then look at to find the metadata about where the document is and how to index it and such. The trouble is, Scrollkeeper and the Gnome help menus no longer support SGML, as XML is the current new and hip thing. The Wine documentation is in SGML. There are quite a few reasons to move forward. The Wine documentation is also a bit separate (requiring its own compiling, for example) from the main code, and this should change. This link: http://scrollkeeper.sourceforge.net/documentation/scrollkeeper_example2_man… has some good information about how Wine should look to play well with Scrollkeeper and modern distros. I propose we attack this in phases, and create the following plan of attack: 1) Create a new directory for all XML documentation at wine/doc. This will also bring us to be more standard. 2) When we convert old SGML documents to XML and move them there, we write an OMF file for them then and there (I'll do it if you like). We also make sure the build process is aware of this stuff and is installing the xml and omf files in the right place so scrollkeeper can find them when it runs after build time. 3) We follow the steps at the above link to add scrollkeeper into the configure scripts after we convert the first document to XML. I vote for the Wine User Guide, since I'm working on it. 4) We inform the packagers once scrollkeeper is working in a release, as there are sometimes little tricks for it (one for rpms is on the page) So, beyond that, the first step seems pretty simple: convert the sgml stuff into xml format and put it into the new doc folder. Can someone point me to some good tools to do this? Thanks, Scott Ritchie

6 8

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Andreas Mohr March 14, 2005

March 14, 2005

Hi, On Mon, Mar 14, 2005 at 09:07:57PM +1100, Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Since you already did testing under Windows, adding proper tests would make sense, I guess... Or in other words: I'm not sure whether your current patch would get applied. Andreas Mohr

1 0

Re: wine/ misc/registry.c documentation/samples/config
by Steven Edwards March 14, 2005

March 14, 2005

Hi, --- Mike McCormack <mike(a)codeweavers.com> wrote: > People would moan and complain, but in the end Wine and Wine users would > be better off, as they would no longer depend on anything but Wine to > run their Windows software. I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing. Thanks Steven __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

8 13

[ARTWORK] icon: "My Computer"
by egore March 14, 2005

March 14, 2005

Hi list, I drew a simple icon that COULD be used as a replacement for the current one. I don't know if anyone of you likes it, so please tell me what you think. Tell me if you like it, if you hate if, what could be done better, etc. The icon can be found in different sizes (and in a scalable format) at http://www.egore911.de/vype/wine/ Regards, Christoph Brill aka egore911

6 6

Re: Wine Start Menu in the Desktop Applications Menu
by Dan Kegel March 14, 2005

March 14, 2005

Jeff Waugh (jeff.waugh_at_ubuntu.com) wrote: >> The PowerPC version of the packages, however, is another issue. >> Obviously, we can't make Wine work with i386-compiled apps on PPC, > > (There's an awesome opportunity for qemu integration there...) Yeah, that's something the folks at http://darwine.opendarwin.org have been thinking about for some time, and to some extent trying. You might give them a shout... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: [X11DRV] Fix X11 Device list leak
by rob March 14, 2005

March 14, 2005

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Raphael fenix-at-club-internet.fr |Wine Mailing Lists| wrote: |Hi, | |Changelog: | - XListInputDevices spec say that device list should be freed using |XFreeDeviceList | - better robustness on X11DRV_AttachEventQueueToTablet | |I hope it helps to fix bug 2017 (http://bugs.winehq.org/show_bug.cgi?id=2017) | |Regards, |Raphael Thanks for submitting this patch. These are exactly the fixes I was about to submit! Your patch should should have a major impact on users of applications which use the wintab library: They should all start to function to some degree. Apologies for not commenting on patch/ submitting a fix earlier.... A major knee operation has put me out of action for the last few weeks. P.S. Please don't expect timely responses to mails for at least another week. I'll try my best to respond, but can't promise anything. Cheers ~ -Rob. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCNPgCKeDvIR8zB68RAgQ3AJ9BA00ZgtZd/HXWy0nOPa3xpWaO3QCfcvVJ RC2lSu6lgqZocJkohkYi/WE= =fFJD -----END PGP SIGNATURE-----

1 0

Re: Borland C++ Buildeer under Wine
by Oliver Stieber March 14, 2005

March 14, 2005

--- Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > It's an old version - 3 IIRC. It starts, but the > Borland window (menu > bar across top) flickers and no other windows open. > I'll see if I've got a copy on a cover disk. CBuilder defiantly used to work. > Andrew > > > > Oliver Stieber wrote: > > --- Andrew Neil Ramage > <nrsc16850(a)blueyonder.co.uk> > > wrote: > > > >>Below is the last three lines of error messages > >>printed when I tried to > >>run Borland C++ Builder under wine. (There were > >>pages and pages of > >>error messages after I hit Ctrl-C in the terminal > I > >>had started BCB.EXE > >>from.) > >> > >>Is this a known bug in Wine ? > >> > >>err:syslevel:_EnterSysLevel (0x40797840, level 2): > >>Holding 0x4083ccc0, > >>level 3. Expect deadlock! > >>err:syslevel:_CheckNotSysLevel Holding lock > >>0x4083ccc0 level 3 > >>err:seh:setup_exception stack overflow 176 bytes > in > >>thread 0009 eip > >>004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000 > >>[andrew(a)zeus BIN]$ > >> > > > > The stack overflow looks like somethings got stuck > in > > a loop, which is problably why there were pages > and > > pages of messages. > > > > What version of CBuilder are you using, CBuilder > <=5 > > used to work. > > > > > http://www.borland.com/products/downloads/download_cbuilderx.html > > CBuilder X claims to run on linux OOTB. > > > > > > I've got standard on the shelf, > > > >>-- > >> > >>Andrew > >> > >>[hackcoughsniffle] > >>Internal Virus Database corrupt > >> > >> > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: Borland C++ Buildeer under Wine
by Oliver Stieber March 14, 2005

March 14, 2005

--- Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > It's an old version - 3 IIRC. It starts, but the > Borland window (menu > bar across top) flickers and no other windows open. > I'll see if I've got a copy on a cover disk. CBuilder defiantly used to work. > Andrew > > > > Oliver Stieber wrote: > > --- Andrew Neil Ramage > <nrsc16850(a)blueyonder.co.uk> > > wrote: > > > >>Below is the last three lines of error messages > >>printed when I tried to > >>run Borland C++ Builder under wine. (There were > >>pages and pages of > >>error messages after I hit Ctrl-C in the terminal > I > >>had started BCB.EXE > >>from.) > >> > >>Is this a known bug in Wine ? > >> > >>err:syslevel:_EnterSysLevel (0x40797840, level 2): > >>Holding 0x4083ccc0, > >>level 3. Expect deadlock! > >>err:syslevel:_CheckNotSysLevel Holding lock > >>0x4083ccc0 level 3 > >>err:seh:setup_exception stack overflow 176 bytes > in > >>thread 0009 eip > >>004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000 > >>[andrew(a)zeus BIN]$ > >> > > > > The stack overflow looks like somethings got stuck > in > > a loop, which is problably why there were pages > and > > pages of messages. > > > > What version of CBuilder are you using, CBuilder > <=5 > > used to work. > > > > > http://www.borland.com/products/downloads/download_cbuilderx.html > > CBuilder X claims to run on linux OOTB. > > > > > > I've got standard on the shelf, > > > >>-- > >> > >>Andrew > >> > >>[hackcoughsniffle] > >>Internal Virus Database corrupt > >> > >> > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0