December 2002 - Wine-Devel - list.winehq.org

Re: Registering DLL's
by Jaco Greeff Dec. 7, 2002

Dec. 7, 2002

On Sat, 7 Dec 2002 01:13:53 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > Cool. Any other details other than "a bit further"? :))) > Like a ETA for a preview version, or something to be > integrated into the tree? *grin* I don't mind ETA's, it helps me focus. Second week in Jan 2003 for a preview and some serious feedback. I've only got about 4 days left before taking a bit of a break hence the longinsh delay. I've wanted to be quite a bit further along and have something out there by now, but this is problably better - it allows me to give serious attention to the feedback in Jan. Greetings, Jaco

1 0

Re: Registering DLL's
by Jaco Greeff Dec. 7, 2002

Dec. 7, 2002

On Fri, 6 Dec 2002 10:32:45 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > On December 6, 2002 10:18 am, you wrote: > > You guys have got the ReactOS regedit based on Wine Regedit although it is > > read only atm. If someone is still planning on adopting it, then that will > > solve this part of the problem. > > Jaco was working on a cool too, I don't know what the status of that is: It is a bit further that the last staus update, we will need to see how it evolves as the configuration moves into the registry. Greetings, Jaco

2 1

RE: Cabinet FDICreate()
by Patrik Stridvall Dec. 6, 2002

Dec. 6, 2002

> The MSXML4 .msi package dies with : > > fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, > 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub > > Is this scheduled to be implemented as part of the cabinet merge in > work? IIRC Greg Turner volunteer to do it however, also said I might take a while before getting around to do it. I, who did the stub, personally, haven't got much time to do it either. So don't hold you breath, unless you volunteer. Implementing it is not that hard I think especially since we got cabextract licensed under the LGPL for us. If not, install and use the native cabinet.dll instead.

2 1

RE: Let --disable-debug actually do something
by Medland, Bill Dec. 6, 2002

Dec. 6, 2002

-----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. And why is the header that defines FIXME an installed include anyway? > > -- > Alexandre Julliard > julliard(a)winehq.com > >

1 0

re: Dll separation question
by Dan Kegel Dec. 6, 2002

Dec. 6, 2002

Martin.Wilck(a)fujitsu-siemens.com wrote: > when writing code for DLL X, which functions from other DLLs may I call? As a Wine outsider, let me make a wild guess: To a first approximation, a nice way of thinking about it might be Write new DLLs using only published Microsoft APIs already implemented in other Wine DLLs. Ideally, new DLLs would work as replacements if compiled and run on a real Windows box. (although of course a whole lot of DLLs probably can't meet that strict definition.) - Dan

2 1

Re: FW: shell32.SHDefExtractIcon implementation take
by Uwe Bonnes Dec. 6, 2002

Dec. 6, 2002

>>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: +/**************************************************************************** + * SHDefExtractIconW [SHELL32.@] + */ +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) +{ + UINT ret; + HICON hIcons[2]; ^^^^^^^^ + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); + + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, nIconSize, h\ Icons, NULL, 2, LR_DEFAULTCOLOR); + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ + if (ret == 0xFFFFFFFF) + return E_FAIL; + if (ret > 0) { + *phiconLarge = hIcons[0]; ^^^^^^^^^^^^ Rolf, this doesn't look right to me: You allocate space on the function local stack, then hand out a pointer to that memory and return from the function. No the function local stack is undefined and the pointers are dangling. I think the heap should be used for allocating the needed storage. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Let --disable-debug actually do something
by Alexandre Julliard Dec. 6, 2002

Dec. 6, 2002

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 -0000 1.5 > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > @@ -23,6 +23,7 @@ > > #include <stdarg.h> > #include "windef.h" > +#include "config.h" You can't do that, installed includes shouldn't depend on config.h. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [RESENT] Batch support for CreateProcess (2 of 3)
by Alexandre Julliard Dec. 6, 2002

Dec. 6, 2002

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > --- wine/programs/wcmd/builtins.c 24 Jul 2002 19:00:25 -0000 1.15 > +++ wine/programs/wcmd/builtins.c 6 Dec 2002 14:04:02 -0000 > @@ -406,7 +406,7 @@ > return; > } > if (test != negate) { > - WCMD_parameter (p, 2+negate, &s); > + WCMD_parameter (p, 2+negate+test, &s); This doesn't look right. The number of parameters doesn't depend on the result of the test. -- Alexandre Julliard julliard(a)winehq.com

1 0

Janitorial Projects
by Dimitrie O. Paun Dec. 6, 2002

Dec. 6, 2002

Folks, I have updated the Janitorial section: http://www.dssd.ca/wine/Wine-Fun.html#janitorial with the list of cross calls from 32->16, and W->A. There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII. Any takers? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.

6 17

how to switch between threads
by Rajesh Akkineni Dec. 6, 2002

Dec. 6, 2002

Hi, I am debugging wine with MS Media Player. Some places the program is blocking with som 7 to 8 threads opened. They are all waiting for a some event(ConnectNamedPipe) But i think there should be another thread with will Create the file or NamedPipe. So How can i see where the other threads are when i set a break point in a perticular method. How dose debuggers handle MultiThreaded Applications? Can i Shit to different Thread to exmine where is it when the program Halted? Thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

RE: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com Dec. 6, 2002

Dec. 6, 2002

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. You're right in theory but you're partly wrong in practice. Some time back I changed a shared library which had been used by ten or so developers for about eight years. I changed all possible unspecified length string copies and concatenates to versions with length limits. The programs using the library crashed less and displayed bad output less. Nobody noticed any speed change there might have been. We all had access to all of the source code involved and none of it was deliberately hostile to the library. The changes caught things the application programmers had missed in their testing and odd or corrupt data which ended up in the databases and made them less harmful. It was then also easier to follow up and fix "the program displayed xyz trash here" than it was to fix "my PC crashed" or "your program died". As programmers we all try to follow the limits and take care with buffer sizes and lengths and validation. We all fail and we all fail to catch every time we fail. That's just the nature of bugs and what we do. Buffer length issues are particularly hard to find and no realistic testing for a project the size of wine will catch them all. Wine also needs to remember that hostile Windows program developers may deliberately try to break programs under wine by passing invalid parameters. Even if wine doesn't check all of those, it shouldn't die when it happens. At least one company has an interest in breaking wine when running its programs and coding defensively is a prudent thing. Performance is unknown and won't be known until any possible shared function is implemented. Just announce it with the length parameter and do it with a define. Let the person who implements it decide whether to use strcat, strlcat or whatever in the first implementation, a function or inline or whatever. Six months or a year from now someone can try different implementations to see whether there is a speed difference. Then they can do something about selecting the most efficient. It's an issue, so deal with it, but there's no way to know today which will be the best implementation because it depends on the data and it is obvious that nobody knows the data well enough to be certain which will work best. If you don't like the strlcat implementeation, then you can try it with strcat and tell everyone how much faster it is when the l is ignored. Or not. Even if the l is eventually ignored in production, having it around offers the opportunity to turn it on with a compile option and/or to use it for assert sanity checking in a debug build. Finally, hi.:) Just started monitoring this list because I'm helping to get a Windows application (OzWin) working under wine. James Day ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

3 2

Registering DLL's
by Jeff Smith Dec. 6, 2002

Dec. 6, 2002

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]" Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg. About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions. Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 4

Cabinet FDICreate()
by Mike Hearn Dec. 6, 2002

Dec. 6, 2002

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: wine/tools Makefile.in .cvsignore mingwrap.c
by Dimitrie O. Paun Dec. 6, 2002

Dec. 6, 2002

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

1 0

Re: Loading Autorun.inf on CD's
by Dustin Navea Dec. 5, 2002

Dec. 5, 2002

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

1 0

[Alsa] A simple test for IDirectSound.GetCaps.
by Sylvain Petreolle Dec. 5, 2002

Dec. 5, 2002

Running the dsound test using winealsa.drv, the program hangs and try to call the debugger. [syl(a)snoop dsound]$ make test make[1]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400bb478 make[1]: Quitte le répertoire `/home/wine/dlls/dsound/tests' According to http://www.delphifaq.com/fq/q1061.shtml, exception c0000194 is STATUS_POSSIBLE_DEADLOCK. How could I debug the tests ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

WineBuild/WineLib <-> MFC
by jaymz＠free.fr Dec. 5, 2002

Dec. 5, 2002

Going further into the MFC dll handling, I raised the following issue: I have two dynamic libs (mfc.dll.so and myapp.dll.so), both loaded by the wrapper (myapp.exe.so). The problem is that global or static class variables are badly exported from mfc.dll.so to myapp.dll.so. Here's an example: In mfc.dll.so, let assume that I export a global integer variable named myVar. I add @ extern myVar myVar in mfc.dll.spec. When I do a GetProcAddress of myVar from the wrapper, the returned address is good, but when I link my application, myVar is undefined (WineBuild did not include it in myapp.dll.spec.c). If I add instead in the spec file something like @ stdcall myVar() myVar, it's still good when using GetProcAdress, I can now link my application, but at runtime, the address of the variable is not the good one, so I'm using corrupted data ! Therefore, when the app runs, all static data are in fact not or badly initialized and it crashes. What's the exact syntact to correctly export class static variable from a dll ? Thanks a lot for your attention.

2 1

[RFC] wrc & windres
by Dimitrie O. Paun Dec. 5, 2002

Dec. 5, 2002

Hi folks, As we discussed here a few weeks ago, there is good reason to have a windres compatible mode for wrc. Needless to say, this will greatly ease porting apps that use windres to Winelib. More information about the issues at hand can be found in this thread: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html That being said, what would it take to (1) keep the current wrc behavior, and (2) make it compatible with windres? First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc -> .res. It would be interesting (from the Winelib point of view) to also support .rc and .res -> .o. The other transformations supported by windres (.o -> .res -> .rc) are not as interesting, as they are not used in the build process. With that in mind, what do we need to do to have said compatibility? Well there are two things: 1. Support windres command line options 2. Add conversion of .rc and .res to .o I will treat each of these below. Command line compatibility -------------------------- Luckily, there is only one (seldom used) option that conflicts: -I. Moreover, it has a long format name in windres as well, which can be used instead. In other words, it should be very simple to add support for the windres options to wrc (most of them will just get ignored). In other words we can support windres's options while keeping full backwords compatibility. Having this compatibility makes sense as long as we support the conversion to .o files as well. Assuming we can do that, I would say this is something we should have. Conversion to .o files ---------------------- As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html generating .o files in proper format is non-trivial. And since I'm willing to do the work, there's no chance I'm going to propose something difficult to implement! :) What I have in mind is quite simple: store the .res file, as a byte array, in a .wine.resources ELF section, and have winebuild pick it up from there (as an alternative to getting it directly from the .res file, so current behavior is conserved). With these two changes, we eliminate the biggest nastiness of getting apps compiled with Winelib. The modification will typically be: -WINDRES=windres +WINDRES=wrc Moreover, the solution is: o Simple to implement o Fully backwards compatible with current Wine practice o Fully compatible with Win32 apps using the MinGW toolchain o Supports multiple resource files, etc. So now the big question: Alexandre, are patches that implement these ideas acceptable? Sorry for the long message, and thanks for reading this far. -- Dimi.

3 6

Re: [RFC] wrc & windres
by Jeff Smith Dec. 5, 2002

Dec. 5, 2002

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> >Hi folks, > >As we discussed here a few weeks ago, there is good reason >to have a windres compatible mode for wrc. <snip> >That being said, what would it take to (1) keep the current wrc >behavior, and (2) make it compatible with windres? Here is an alternative idea for dealing with command-line incompatibility: create a link 'windres' pointing to 'wrc'. In the program, we could determine how the program was invoked and handle the command-line options accordingly. This should technically work, unless we find some reason to 'mix' command line options, in which case we we would have to start 'blending' the two syntaxes. Please note that I am not familiar with the command line options of either program. <snip> >The modification will typically be: >-WINDRES=windres >+WINDRES=wrc WINDRES would not have to be changed using this method. -- Jeff S. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

Re: possible memory corruption
by steve.lustbader＠philips.com Dec. 5, 2002

Dec. 5, 2002

>>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: > > steve> When I try to load a window in my app that has a treeview in it, > steve> it crashes immediately, before the window even gets displayed. > steve> This is the end of the backtrace: > > Try running with native commctrl to see if the corruption comes from our > commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will > check on every heap manipulation to see if the heap is still okay. Then >look what corrupted the heap. It works fine with a native (WinXP) comctl32.dll. I'll post the +relay,+heap output shortly. -Steve

1 0

possible memory corruption
by steve.lustbader＠philips.com Dec. 5, 2002

Dec. 5, 2002

When I try to load a window in my app that has a treeview in it, it crashes immediately, before the window even gets displayed. This is the end of the backtrace: 0x400d6377 (HEAP_FindFreeBlock+0x3b [heap.c:608] in libntdll.dll.so): movl 0x0(%edx),%eax 608 DWORD arena_size = (pArena->size & ARENA_SIZE_MASK) + Wine-dbg>bt Backtrace: =>0 0x400d6377 (HEAP_FindFreeBlock+0x3b(heap=0x41230000, size=0x108, ppSubHeap=0x406e1af4) [heap.c:608] in libntdll.dll.so) (ebp=406e1adc) 1 0x400d6df5 (RtlAllocateHeap+0x71(heap=0x41230000, flags=0xa, size=0x104) [heap.c:1028] in libntdll.dll.so) (ebp=406e1b04) 2 0x40b283e2 (COMCTL32_Alloc+0x4a(dwSize=0x104) [comctl32undoc.c:352] in comctl32.dll.so) (ebp=406e1b24) 3 0x40b732bb (TREEVIEW_UpdateDispInfo+0x227(infoPtr=0x41230838, wineItem=0x41232060, mask=0x1) [treeview.c:762] in comctl32.dll.so) (ebp=406e1ba4) 4 0x40b73d94 (TREEVIEW_InsertItemA+0x324(infoPtr=0x41230838, lParam=0x406e1be8) [treeview.c:1318] in comctl32.dll.so) (ebp=406e1bd8) 5 0x40b73eb6 (TREEVIEW_InsertItemW+0xb2(infoPtr=0x41230838, lParam=0x406e1f08) [treeview.c:1389] in comctl32.dll.so) (ebp=406e1c34) 6 0x40b79881 (TREEVIEW_WindowProc+0x6a5(hwnd=0x2006a, uMsg=0x1132, wParam=0x0, lParam=0x406e1f08) [treeview.c:5237] in comctl32.dll.so) (ebp=406e1c50) 7 0x408ec923 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406e1c74) 8 0x408ec9ae (WINPROC_CallWndProc+0x82(proc=0x40b791dc, hwnd=0x2006a, msg=0x1132, wParam=0x0, lParam=0x406e1f08) [winproc.c:183] in user32.dll.so) (ebp=406e1ca4) I had thought originally that it might be a treeview problem, since the crash happens based on calls from treeview, but Dimi says that it's probably memory getting corrupted somewhere. What trace would be helpful to debug this? Thanks, Steve, PS - I had previously posted a +treeview trace a couple of weeks ago. Here it is again, just in case it's helpful: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger...

2 1

valgrind and wine
by Dan Kegel Dec. 5, 2002

Dec. 5, 2002

valgrind wine reports: ==6476== Valgrind detected that your program requires ==6476== the following unimplemented functionality: ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. ==6476== This may be because the functionality is hard to implement, ==6476== or because no reasonable program would behave this way, ==6476== or because nobody has yet needed it. In any case, let me know ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Dang. - Dan

3 4

RE: Remnants of -DSTRICT Conversion
by Patrik Stridvall Dec. 5, 2002

Dec. 5, 2002

> Just a small request. Could someone write a script that would > remove one of > the last remnants of the -DSTRICT conversion. It is a little > issue with lots > of 0x%p's everywhere (mainly in NTDLL registry functions) > which need to be > replaced by just %p's. Sure here is the script: find . -name \*.c | xargs perl -i -pe 's/0x%p/%p/g' and as a bonus to Alexandre here is the patch. --8<--- *** strict * dlls/commdlg/filedlg95.c, dlls/ntdll/file.c, dlls/ntdll/heap.c, dlls/ntdll/misc.c, dlls/ntdll/nt.c, dlls/ntdll/om.c, dlls/ntdll/reg.c, dlls/ntdll/sec.c, dlls/ntdll/sync.c, loader/module.c, scheduler/process.c, scheduler/thread.c, win32/device.c: Replace 0x%p with %p.

1 0

Remnants of -DSTRICT Conversion
by Robert Shearman Dec. 5, 2002

Dec. 5, 2002

Hi all, Just a small request. Could someone write a script that would remove one of the last remnants of the -DSTRICT conversion. It is a little issue with lots of 0x%p's everywhere (mainly in NTDLL registry functions) which need to be replaced by just %p's. Thanks, Rob

1 0

Use COMSPEC command interpreter to run .bat files.
by Sylvain Petreolle Dec. 4, 2002

Dec. 4, 2002

Is your patch allowing the run of .bat files by wine itself, or only a W-process ? When I try it on command line I have this : [syl(a)snoop cygwin]$ wine cygwin.bat --debugmsg +process trace:process:PROCESS_InitWine starting process name="" file=(nil) argv[0]="cygwin.bat" trace:process:find_exe_file looking for "cygwin.bat" trace:process:find_exe_file Trying built-in exe "C:\\cygwin\\cygwin.bat" trace:process:find_exe_file Trying native exe "C:\\cygwin\\cygwin.bat" wine: cannot determine executable type for 'C:\cygwin\cygwin.bat' [syl(a)snoop cygwin]$ cat cygwin.bat @echo off C: chdir \cygwin\bin bash --login -i ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

5 14

Wine Janitorial Projects
by Dimitrie O. Paun Dec. 4, 2002

Dec. 4, 2002

Hi folks, The Wine Janitorial Project section has grown to the point where a separate page is warranted. It's been *greatly* enhanced, hopefully making the tasks a lot more explicit, easier to understand, and track. The first release of this page is available at: http://www.dssd.ca/wine/Wine-Janitorial-0.1.html As you are probably used to by now, the working version can be found here: http://www.dssd.ca/wine/Wine-Janitorial.html Please feel free to suggest new projects for the list. There are many things to cleanup in the tree, and having them available on an easy to read page increase the changes of (1) someone picking them up, and (2) us not forgeting them. So let me know if you come across anything that you feel should be on the list. Also, if you're working on something big, I can mark your name there so we can avoid duplicated work. Last but not least, there are a lot of small, self contained, and easy to get into tasks listed there. If you feel like getting your feet a bit wet in Wine development, this is an ideal opportunity to start, and get to know the project a little better. Just ask for help if you are new, and would like some help to get you started. -- Dimi.

2 2

Re: rpc_J_PL4
by Greg Turner Dec. 4, 2002

Dec. 4, 2002

On Wednesday 04 December 2002 02:31 am, Francois Gouget wrote: > On Wed, 4 Dec 2002, Greg Turner wrote: > [...] > > > Anyhoo, yes, I like something like what you are doing better, it > > seems that if anything might just break out of the blue, it would > > be the unicode version, right? So I should have done more like > > that and that way wine doesn't lose the test. knowing there's no > > crash involved makes the difference, I guess. > > Submitting for inclusion then :-) well, if it doesn't crash, I say we'd might as well run the tests but show traces instead of "ok"'s on failure.... I really wish there was a "whatever" macro that took the same syntax as "ok" but didn't constitute failure (or is there? perhaps I should make one?) Anyhow, until I make my mind up or whatever, Francois' patch is fine by me, considered rpc_J_PL4-r0 if it's OK to call it X11. -gmt

2 1

Re: Registering DLL's
by Jeff Smith Dec. 4, 2002

Dec. 4, 2002

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On December 4, 2002 01:36 pm, Jeff Smith wrote: > > Does anyone have any better ideas on what the "Right Way" to tackle > > this item is? I am sure that adding external functions that do not > > exist in native versions is *not* the way. > >This was Alexandre's idea. Alexandre, a more detailed brain dump on >the configuration stuff would be useful. For example: > >C.1 Merge configuration into the registry > >Any gochas? What would it take? > >C.5 Make Wine's DLLs register themselves to avoid manual merging of the >winedefault.reg > >How should this be implemented? See Jeff's questions. > >C.6 Write wine.inf script to setup a new Wine installation > >Do we have the code that executes .inf scripts? Is this one >just a matter of writing the scripts? > >-- >Dimi. For those interested, here are a couple of links relating to the INF file format (1), and the SetupAPI (2). I don't know how complete our implementation is, but it can be found under wine/dlls/setupapi. 1.) http://msdn.microsoft.com/library/en-us/install/hh/install/create-inf_4l47.… 2.) http://msdn.microsoft.com/library/en-us/install/hh/install/setupapi_2faf.asp -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

what happened wineboot?
by Matthew Davison Dec. 4, 2002

Dec. 4, 2002

I have been trying to get programs installed which place entries in RunOnce. I read a while ago about a wineboot program which automates these jobs, thus simulating a reboot, similar to what crossover does. Does anyone have such a program, as I have been looking for it and cant find it. -- Matthew Davison <m.davison(a)virgin.net>

2 1

Re: Dll separation question
by Rolf Kalbermatter Dec. 4, 2002

Dec. 4, 2002

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> wrote: >I am sorry to say that I still don't quite understand this issue, but - >can anybody point me to a resource saying what exactly I may or may not >do when writing code for a wine DLL? In particular, when writing code >for DLL X, which functions from other DLLs may I call? This interests me as well! >Example: When writing netapi32 code, can I call advai32 Registry >functions to obtain config options, or do I need to use the (IMO rather >awkward) ntdll interface ? I was under the impression that the main issue was that no DLL calls not officially exported functions in any other DLL, with officially exported meaning any function which is not wine specific eg. is also exported by the according MS Windows DLL. I have gotten the impression that all Wine specific exports start with the uppercase name of the DLL which implements them followed by an underscore and then the actual name and the main and final target is to get rid of any and all exports of such functions. So in general I would think that usage of the Reg.. functions from ADVAPI32 should be ok, but I'm not familiar with NETAPI32 at all and how it relates to the rest of Win. Maybe it is more considered part of the actual Win kernel and therefore should maybe call the Nt... functions in NTDLL. But the Reg... functions are really just a convinience wrapper around the according Nt... functions and ADVAPI32 is certainly a well known standard DLL. >Btw: Dll separation is a really complex issues and I think I'm not the >only one who feels he doesn't quite understand what it means. IMO winehq >needs a very clear description of that somewhere where it's easy to find. Some documentation or a link to them would certainly help. Rolf Kalbermatter

1 0

Dll separation question
by Martin Wilck Dec. 4, 2002

Dec. 4, 2002

I am sorry to say that I still don't quite understand this issue, but - can anybody point me to a resource saying what exactly I may or may not do when writing code for a wine DLL? In particular, when writing code for DLL X, which functions from other DLLs may I call? Example: When writing netapi32 code, can I call advai32 Registry functions to obtain config options, or do I need to use the (IMO rather awkward) ntdll interface ? Btw: Dll separation is a really complex issues and I think I'm not the only one who feels he doesn't quite understand what it means. IMO winehq needs a very clear description of that somewhere where it's easy to find. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Painting message order?
by Mike Hearn Dec. 4, 2002

Dec. 4, 2002

Hi all, My beloved SVG plugin broke again :( For some reason it's not repainting properly, in fact, the only way I can force it to repaint when running in wine desktop, internet explorer kiosk mode (ie it fills a window) is by toggling high quality/low quality which controls antialiasing. trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT sent from self wp=00000001 lp=00000000 trace:message:SPY_EnterMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] wp=00000001 lp=00000000 trace:message:SPY_ExitMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] returned 00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT returned 00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND sent from self wp=000008a8 lp=00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND returned 00000001 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT returned 00000000 That's a message trace of the paint cycle (when I make it paint by minimizing the wine window for instance. It sends WM_PAINT, the does the NCPAINT thing which seems to be do do with window borders, and then some ERASEBKGND messages come from somewhere. I have a sneaking suspicion that the background gets erased after it's painted and not before, but that's a total shot in the dark and the absence of flicker kind of makes my theory look not so strong. I did some traces with +gdi as well, but it wasn't very helpful. There were lots of GetObjPtr and locking methods called, but I didn't see any actual obviously drawing related calls. There was 1 warning: GetObjPtr was called at one point with nil. What does this mean? I can't find any documentation about GetObjPtr on google. I'll look at the sources later to see if I can figure out what's wrong. Anyway, my final question is : is there a way to alter the colour with which the background is erased? Even if it screws up rendering elsewhere just for debugging i'd like to see if I can make it display as anything *except* offwhite. If so then it confirms my theory. Or are those messages processed by the plugin itself? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 3

Re: Fix winsock conformance test on Windows NT
by Francois Gouget Dec. 4, 2002

Dec. 4, 2002

On 4 Dec 2002, Martin Wilck wrote: > Am Mit, 2002-12-04 um 10.21 schrieb Francois Gouget: > > > sock.c:456: Test failed: event_client (ea): connect error: 10022 > > I could reproduce that on NT4. [...] > But setting the socket to overlapped mode helps. So with the > following one-liner we should be fine. Yep, that works. Thanks :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

1 0

Vstserver v0.2.0
by Kjetil S. Matheussen Dec. 4, 2002

Dec. 4, 2002

http://www.notam02.no/arkiv/src/ VSTServer V0.2.0. ----------------- GRM tools 1 runs with the 25.11.2002 release of wine. ABOUT Vstserver is a program that must be running when using programs using vstlib. Vstlib is a library that can be used by programs to run windows vst audio plugins under linux/freebsd/i386solaris/etc. RUNNING First you should set the "VST_PATH" environment variable pointing to the directory where your VST dll files are placed. Then to run the vstserver program, you have to cd into the directory where the "vstservant.so" file is placed (and thats most probably the directory where this README file is placed), and then run the "vstserver" program. DEVELOPMENT Vstserver is released under the GPL, and vstlib under LGPL. If there comes many source-contributions, I will probably make it a sourceforge project. To use vstlib in a program, look at the tests/exampleclient program, and various vst plug-in documentation. The interface to the vstlib consists only of two functions (new/delete), the rest is like you would do when programming for windows, macos(X), beos, irix, etc. You do currently not have access to the audioMaster callback function from a client. If you need access to it, please contact me, and I'll extend the library and the vstservant program. CURRENT STATUS Vstserver seems to be very stable. Very few vst plug-ins and instruments wont run, and I am not able to hear any latency. And plug-ins does not seem to cause more cpu-power than under windows. BUGS 1. When loading a lot of plugins simultaniously, the X server crashes (!). I manage to do that when running the ladspa "listplugins" program _many_ times in a row like this: "listplugins &". I dont know the cause of it. (running redhat 7.2, with latest XFree rpm updates installed) 2. Shared memory handlig might be faulty. I suspect that it doesnt free resources because clients sometime complains about not getting shared memory. (see server/shmhandler.c) 3. The graphics code to support gui is just hacked together by looking at the winemine source-code included with the wine distribution. I have no windows programming experience or documentation about the windows API, so if someone that have windows programming experience would have a look at the code and check that its fine/not fine, that would be, eh, fine. (The code I'm unsure about is server/win/winwin.c and server/win/main.c, about 200 lines of code.) NOT WORKING DLLS - "SimSynth VSTi demo.dll" - The standalone version wont even run under wine, so theres currently not much hope for this one. Please send me dlls that wont work. FUTURE -Make a DX-plugin server. (would be fun running pi-warp under linux). -Add gui to the plugins not providing gui themselves. (help wanted, windows programming) HISTORY 0.1.1 -> 0.2.0: -When upgrading my wine installation from the 31.10.2002 version to the 25.11.2002 version, the "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" problem got much worse. So I changed the vstserver program to be a normal unix program that starts a winelib program called "vstservant.so" for each new request it gets. This seems to have solved the GDI heap problem totally. -Extended the audioMaster function yet more by copying a lot of opcode handlings from the vst~ pd external by Mark Williamson. I didn't ask before doing this, but according to the pdf file, he used some code from the plugin~ external, which then should automaticly make vst~ GPL. The positive result is that more plugins works. The negative result is that you now need to patch the steinberg "vst/aeffectx.h" file before compiling, as there are some strange things in it. -Some smaller fixes here and there. 0.1.0 -> 0.1.1: -Replaced the old audioMaster function in the server with the one coming from the plugin~ source by Jarno Seppänen. Result is that GRM tools 2 now works. (I thought there were a different reason it didnt work before, without going into further detail...) Seems like vst instruments works better now too. The mousedrag problem seems to have dissapeared. -Removed some debug printings. 0.0.2 -> 0.1.0: -Added graphics support to the plug-ins. (effEditOpen/effEditClose dispatch opcodes works.) -Fixed the makefile a bit. 0.0.1 -> 0.0.2: -Fixed the process function in vstlib. -Fixed the problem with processreplace could fail if sampleframes was to high. -Added processreplace simulation to vstlib, in case plugin doesnt implement processreplace itself. CREDITS vstserver and vstlib are made by Kjetil S. Matheussen / Notam. k.s.matheussen(a)notam02.no Some programming hints is gathered by looking at the pd vst-object plugin~ source and the jack soundserver source. --

1 0

Re: The conformance tests need you!
by Martin Wilck Dec. 4, 2002

Dec. 4, 2002

Am Mon, 2002-12-02 um 19.12 schrieb Francois Gouget: > > Am Sam, 2002-11-30 um 04.02 schrieb Francois Gouget: > > > > > > Come on people, we can do better. > > > Send fixes to wine-patches, and send me emails to so that I update this > > > table. > > > > I'll have a look at the winsock stuff. > > Thanks :-) I am currently having trouble with running stuff natively on Windows. Can anybody run the winsock test with verbose output (trace enabled) on Windows NT and send me the result ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

3 3

Re: Fix winsock conformance test on Windows NT
by Francois Gouget Dec. 4, 2002

Dec. 4, 2002

On 3 Dec 2002, Martin Wilck wrote: > > With the following fixes, the winsock test runs fine (0 errors) on Win > NT (and Wine!). I applied the patch but the test still fails and gets stuck on NT4: sock.c:694: **** STARTING TEST 0 **** sock.c:332:simple_server (d3) starting sock.c:341:simple_server (d3) ready sock.c:346:simple_server (d3): waiting for client sock.c:391:simple_client (dd): starting sock.c:394:simple_client (dd): server ready sock.c:391:simple_client (b9): starting sock.c:394:simple_client (b9): server ready sock.c:406:simple_client (dd) connected sock.c:346:simple_server (d3): waiting for client sock.c:427:simple_client (dd) exiting sock.c:406:simple_client (b9) connected sock.c:374:simple_server (d3) exiting sock.c:427:simple_client (b9) exiting sock.c:696: **** TEST 0 COMPLETE **** sock.c:694: **** STARTING TEST 1 **** sock.c:332:simple_server (ec) starting sock.c:341:simple_server (ec) ready sock.c:346:simple_server (ec): waiting for client sock.c:445:event_client (ea): starting sock.c:445:event_client (e3): starting sock.c:447:event_client (ea): server ready sock.c:456: Test failed: event_client (ea): connect error: 10022 sock.c:447:event_client (e3): server ready sock.c:456: Test failed: event_client (e3): connect error: 10022 It stays there for a long time and then prints: sock.c:456: Test failed: event_client (e3): connect error: 10022 sock.c:614: Test failed: some threads have not completed: 102 sock.c:621:terminating thread 000000ec sock.c:621:terminating thread 000000ea sock.c:621:terminating thread 000000e3 sock.c:696: **** TEST 1 COMPLETE **** But then the process does not terminate... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

2 1

Re: Direct3D8 regression/bug
by Sylvain Petreolle Dec. 4, 2002

Dec. 4, 2002

--- Greg Turner <gmturner007(a)ameritech.net> a écrit : > On Tuesday 03 December 2002 02:34 pm, Sylvain Petreolle wrote: > > NVidia and its bugged binary shit... > > yuck. doesn't xfree or drm-kernel project provide a decent driver > for > you guys? the nv driver provided with Xfree is way too slow to use it on Wine. and I don't want to have to compile Xfree myself. You wrote exactly what I wanted to avoid when I put "mplayer.exe" It isn't mplayer from mplayerhq.hu, but windows mplayer.exe from Windows ME. I need it to test midi with winealsa.drv. Now I didn't succeed because of Registry glitch: couldn't find midi out (%s)\n > > Note : it crashes even with mplayer.exe !! > > mplayer is very, very agressive and takes wierd liberties with > compiler > flags. compile it yourself, disable stuff you don't want, and pay > attention to the compiler flags you get. when all is said and done > ... ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

3 4

Cygwin/wine : partial success
by Sylvain Petreolle Dec. 4, 2002

Dec. 4, 2002

Making only one tweak to /etc/profile, cygwin manages to launch partially. If you comment the line USER="`id -un`", bash -l -i displays : (I placed "I'm here!" at the end of .bahrc) C>bash -l -i I'm here! syl(a)snoop ~ $ logout C> The next step will be identify the reason why it just logs out. I tried zsh but it says zsh: error on TTY read: permission denied and then I have no keyboard in wcmd. mc begin to display itself,then makes disappear the wcmd window, the program doesn't terminate. (??) ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

Re: Direct3D8 regression/bug
by Jeff Smith Dec. 4, 2002

Dec. 4, 2002

>From: Greg Turner <gmturner007(a)ameritech.net> > > > I need it to test midi with winealsa.drv. > > Now I didn't succeed because of Registry glitch: couldn't find midi > > out (%s)\n > >gotcha. I run winealsa too... but I've never tried midi. My buddy owns >cakewalk, I should give it a whorl sometime, and see what happens. >From what I can see in the source, winealsa only supports wave out at this time. I just recently started running ALSA (because its MIDI implementation is much better for my card than OSS), but am using OSS emulation + wineoss for midi from wine. It worked beautifully for me (after I made a couple of fixes, now in CVS). -- Jeff S _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: rpc_J_PL4
by Francois Gouget Dec. 4, 2002

Dec. 4, 2002

On Tue, 3 Dec 2002, Greg Turner wrote: > License: X11-MIT > > Changelog: > > * programs/rpcss/tests: rpc.c: > Greg Turner <gmturner007(a)ameritech.net> > - W9x doesn't support widechar uuids (crashes on test) That surprises me. I ran these tests on Win95 and Win98 and they failed but did not crash. Thus I think it would be better to apply this patch instead: Index: dlls/rpcrt4/tests/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/rpcrt4/tests/rpc.c,v retrieving revision 1.1 diff -u -r1.1 rpc.c --- dlls/rpcrt4/tests/rpc.c 7 Oct 2002 21:54:07 -0000 1.1 +++ dlls/rpcrt4/tests/rpc.c 4 Dec 2002 07:29:22 -0000 @@ -101,7 +101,12 @@ /* Uuid to String to Uuid (wchar) */ for (i1 = 0; i1 < 10; i1++) { Uuid1 = Uuid_Table[i1]; - ok( (UuidToStringW(&Uuid1, &wstr) == RPC_S_OK), "Simple UUID->WString copy" ); + rslt=UuidToStringW(&Uuid1, &wstr); + if (rslt==RPC_S_CANNOT_SUPPORT) { + /* Must be Win9x (no Unicode support), skip the tests */ + break; + } + ok( (rslt == RPC_S_OK), "Simple UUID->WString copy" ); ok( (UuidFromStringW(wstr, &Uuid2) == RPC_S_OK), "Simple WString->UUID copy from generated UUID String" ); ok( UuidEqual(&Uuid1, &Uuid2, &rslt), "Uuid -> WString -> Uuid transform" ); /* invalid uuid tests -- size of valid UUID string=36 */ With this patch, all tests are run on NT and Wine platforms, and on Win9x platforms, all tests are skipped after the first first Unicode call. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 1

spec file definitions
by Rolf Kalbermatter Dec. 4, 2002

Dec. 4, 2002

I have seen some definitions of functions in a spec file where a string was defined as str or wstr. I do remember that there was an issue with this depending if the string parameter was input only (eg. const) or an input/output parameter. Is this still valid and if yes how are the rules? Rolf Kalbermatter

2 1

Installing Internet Explorer without windows
by Boris Dec. 3, 2002

Dec. 3, 2002

I just tried installing IE 5.5 from setup.exe and it never seems to install properly without windows being installed or modifying files. It would be nice to install Internet Explorer without patching anything. I hope more people work towards that.

3 2

HTML Help and IWebBrowser status
by Ender Dec. 3, 2002

Dec. 3, 2002

Hi all, I'm just posting a quick update on my various WINE work for those intrested. I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet). Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :) That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy. Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes. I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider: - It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's. - It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out. Cheers, Ender

6 5

Reducing the header maze (warning: long, unsuitable for children)
by Greg Turner Dec. 3, 2002

Dec. 3, 2002

I'm working on Ove's comhdr1 & comhdr2 patches. So far, so good, btw -- I have it compiling against yesterday's CVS (recent commits are not folded in yet). I'll submit after I kick the tires a bit and make sure everything seems to be working (otherwise, I'll probably post it here and ask for help). Anyhow, this project has served to remind me just how deep, and how confusing, the maze of wine headers can really be. It's clear to me that lots of header inclusions are just historical remnants, that no longer serve any purpose, and, conversely, that many implicit header dependencies exist that happen to be hidden, and missing (i.e., X.h needs Y.h, but all references to X.h happen to occur after Y.h was already included, so there's no compile failure). A third kind of unnecessary (but arguably correct, in many cases) dependency is created when an include file is pulled in that is already pulled in by some prior include... This negatively affects wine development because (a) it's hard to change things, the headers break too easily, and (b) the make process rebuilds stuff that doesn't need rebuilding when things change (unavoidable, to an extent, of course, but perhaps it's too much right now). Now, here's my question: couldn't we build a script to automatically fix some of these problems? Imagine this pseudocode as a bash script, makefile, or something along those lines: o gather and create a table of all .c -> .h and .h -> .h dependencies o for each file: o one by one, try removing each reference to a header, and see if the affected units still compile. If they all do, permanently remove that reference, but remember it was there at this point we should have approximately the minimum number of header references in the code to compile wine. But some of the header references we eliminated were probably legitimate dependencies, event though we compiled OK, as mentioned above... so now we: o for each header, try to compile a "Hello World" which includes just that header file. If it fails (or even generates warnings): o for each header reference that was eliminated, try putting it back in. If still failing, try different combinations (this could become a really nasty computation with all kinds of permutations possible, but if certain simple tricks don't work, we can just give up). o if we couldn't find any way to fix it, mark the header for human review. This should ensure that each header can actually be run through the compiler all by itself -- that is, that it #include's any headers it relies on to compile. Finally... o A human picks up the pieces and fixes the breakages o The whole heuristic can start over, now, until the results start to look repetitive or trivial... I can think of some reasons this might not work out so well as I might hope, but... what do you guys think? is such a test meaningful? Is there some tool that already automates this type of investigation, or some better way to achieve the same thing? Would it be, in your opinion, too much work for too little benefit? FWIW, I can probably think of more enjoyable tasks to spend my time on... but OTOH I am really tired of waiting for wine to build on my aging pc -- anything that could speed up the build process would probably save me some from some discomfort, and others too. (At least there's no C++ in there; I'm rebuilding my system lately (I killed it over the holidays messing with glibc), and building stuff like KDE, mozilla, sun-java, and openoffice makes wine look pretty darn svelte! g++ 3.2.1 just crawls; the more "object oriented" the source is, the longer it seems to take to compile... :( ) Just "thinking out loud," probably a terrible idea, but let me know what you think, anyways... -- gmt p.s., I was kidding about unsuitable for children... but then, not sure why children should want to read this -- or adults, for that matter :P

4 4

Re: Fwd: Re: [putty]Winelib support + patch
by Alexandre Julliard Dec. 3, 2002

Dec. 3, 2002

Francois Gouget <fgouget(a)free.fr> writes: > I am not sure but I suspect the compiler generates indirect accesses for > these. I'm not sure what gcc does for variables exported from another > library. It seems like it has to be doing something similar. So if we > could get access to that indirection we may be able to make things work. Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Fwd: Re: [putty]Winelib support + patch
by Dan Kegel Dec. 3, 2002

Dec. 3, 2002

Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> I am not sure but I suspect the compiler generates indirect accesses for >> these. I'm not sure what gcc does for variables exported from another >> library. It seems like it has to be doing something similar. So if we >> could get access to that indirection we may be able to make things work. > > Yes, it would be possible to resolve imports directly through the ELF > tables and avoid our own separate import mechanism; basically this > would be a PE-aware ld.so. It's quite a bit of work though, and > portability is an issue. In any case it's for after 1.0 IMO. Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/ http://groups.google.com/groups?selm=20020516061929.5DA943C110%40gabi-n.hau… et seq. http://www.freebsd.org/cgi/man.cgi?query=compat_pecoff&manpath=NetBSD+1.6 - Dan

3 5

RE: Compiling out the debug messages
by Medland, Bill Dec. 3, 2002

Dec. 3, 2002

> -----Original Message----- > From: Jeff Smith [mailto:whydoubt(a)hotmail.com] > Sent: Tuesday, December 03, 2002 2:13 PM > To: Bill.Medland(a)accpac.com; wine-devel(a)winehq.com > Subject: Re: Compiling out the debug messages > > > Bill, > > Unless I missed the whole point, you gave the answer before asking the > question. > > ./configure > > should have been > > ./configure --disable-debug You are correct; I made a right fist of writing the email. I did actually remember the --disable-debug. > > -- Jeff S > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus >

1 0

Re: Compiling out the debug messages
by Jeff Smith Dec. 3, 2002

Dec. 3, 2002

Bill, Unless I missed the whole point, you gave the answer before asking the question. ./configure should have been ./configure --disable-debug -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Compiling out the debug messages
by Medland, Bill Dec. 3, 2002

Dec. 3, 2002

I know I don't know what I am doing, but.. The documentation says that to compile out the trace, warning and fixme messages I should specify --disable-debug when running configure. So I try ./configure make depend make <build an rpm and install it on another machine> <run wine> <stare at the fixme messages, swear etc.> I presume that if I look for example in the dlls/user/Makefile at this stage I should see NO_DEBUG_MSGS and NO_TRACE_MSGS somewhere, but I don't. Please can someone explain how this is supposed to work and where I have probably gone wrong. (e.g. where should I see the NO_DEBUG_MSGS) Bill Medland

2 1

Re: wtypes.idl patch
by Alexandre Julliard Dec. 3, 2002

Dec. 3, 2002

Ove Kaaven <ovehk(a)ping.uio.no> writes: > You need to regenerate wtypes.h (and it's best to apply my latest widl > patch first). Should regenerated .h files be part of submitted patches in > the future? For me that's not necessary; maybe for others who would like to review the patch, but I doubt many people are going to review the auto-generated stuff anyway. Just do what's easiest for you. -- Alexandre Julliard julliard(a)winehq.com

1 0