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

Direct3D8 regression/bug
by Roderick Colenbrander Dec. 3, 2002

Dec. 3, 2002

Hi, Just to see how well Wine's Direct3D8 support is working, I played with some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades used when he started Wine's Direct3D8 implementation) A few weeks ago all those demo's worked. Perhaps some things where not rendered correctly but they worked. A few days ago I rechecked those demo's but now all d3d8 apps I try crash. Immedeately winedbg is launched. The app seems to crash in libGL.so.1. Here's the error with a backtrace: Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x40bf4a06). In 32-bit mode. 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) Lionel suggested that his OpenGL patches may have caused this problem. He had the same crashes on his pc. I reversed his patches but it still had problems. (perhaps I made some misstakes somewhere ..) Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's OpenGL drivers (1.0-3123). I hope this helps a bit, Roderick Colenbrander

2 2

WIN_FindWndPtr
by Dustin Navea Dec. 3, 2002

Dec. 3, 2002

Hey just out of curiosity, now that we are working toward v1.0 (not like we werent before) shouldnt this error be changed over to a fixme? It doesnt seem like all that much needs to be done (aside from marshalling and whatnot). Just wondering if we were planning on fixing it before v1.0, as it would be a big boon to have it still there in v1.0... -Dustin

1 0

bug (regression) in ddraw/d3d
by J. Hoffmann Dec. 3, 2002

Dec. 3, 2002

Hi, I wanted to play around with the improvements to ddraw/d3d, and tried to run Final Fantasy 8 which worked before in software rendering mode with the native direct music dlls. Unfortunately FF8Config (and FF8 itself) crashes now with the recent changes. The patch which introduces the regression is: http://www.winehq.com/hypermail/wine-cvs/2002/11/0231.html (cvs version just before the patch works, applying the patch results in a pagefault.) The problem appears to be that GL_IDirect3DImpl_3_CreateDevice gets called with an rclsid = IID_D3DDEVICE2_OpenGL instead of IID_D3DDEVICE3_OpenGL, so that an D3DDevice2 gets created for the Direct3D3 interface (which results in a pagefault later, when the device is used.) See traces below. Im still trying to find the bug (and then a fix :-), but it would help me a lot, if someone could tell me where the GL_IDirect3DImpl_3_CreateDevice gets called from. (I see that it is an entry in the vtable but haven't found the function there it gets gets called yet..) regards, Jens Hoffmann ** trace for the old version: (cvs 11/24/02 16:14:09 CST) ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4568)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x40852 3cc) trace:ddraw:direct3d_create creating implementation at 0x403a5380. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a5384. trace:ddraw:Main_DirectDraw_AddRef (0x403a4568)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a5380/0x403a5384)->({31416d44-86ae-11d2-822d-a8d53187cafc},0x403a4e28,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4e28, d3d = 0x403a5380 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x80a0260) trace:ddraw:d3ddevice_create setting current context err:ddraw:set_context This function should not be called in the current state of the code... trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a5770. trace:ddraw:create_device_helper returning OpenGL D3DDevice3 (nil) trace:ddraw:Thunk_IDirect3DDeviceImpl_3_EnumTextureFormats (0x403a5774)->(0x405393,0x42e014) thunking to IDirect3DDevice7 interface. ... ** trace for cvs head: ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4540)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x408523cc) trace:ddraw:direct3d_create creating implementation at 0x403a54b0. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a54b4. trace:ddraw:Main_DirectDraw_AddRef (0x403a4540)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a54b0/0x403a54b4)->({31416d44-86ae-11d2-822d-a8d53187cafb},0x403a4f18,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4f18, d3d = 0x403a54b0 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x809f818) trace:ddraw:d3ddevice_create setting current context trace:ddraw:set_context glxMakeCurrent 0x80690c0, 62914563, 0x809f818 trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a55e8. trace:ddraw:create_device_helper returning OpenGL D3DDevice2 0x403a55f0 trace:ddraw:Thunk_IDirect3DDeviceImpl_2_NextViewport (0x403a55f0)->(0x405393,0x42cb40,00000000) thunking ...

2 3

Re: Wine 0.9 TODO v0.6
by Z_God Dec. 2, 2002

Dec. 2, 2002

First, would it be an idea to say at least *insert any number* of Windows apps should be working perfectly with Wine before it is called 0.9? For example, we at least want to have 200 known perfectly working apps. And why not start at version 0.6 or something and calling Wine beta software instead of alpha when these TODOs are done? Then it would be possible to work towards a great 1.0 release. Just look at Mozilla, they post-poned their 1.0 release more than a year to become really great. Keep up the great work!! Z_God Op maandag 2 december 2002 19:40, schreef Dimitrie O. Paun: > Hi folks, > > Version 0.6 of the TODO for Wine 0.9 is available at: > http://www.dssd.ca/wine/Wine-0.9-TODO-0.6.html > As always, you can find the work-in-progress one here: > http://www.dssd.ca/wine/Wine-0.9-TODO.html > > As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment > -- A5: New FAQ is done, waiting to be promoted to WineHQ > -- D2: Alexandre got rid of the rsrc directive in .spec files > -- E4: Lionel made OpenGL detection dynamic > -- E9: New TODO item for fixing header location as discussed on > wine-devel > > Enjoy!

2 1

Programs to test D3D
by J C Dec. 2, 2002

Dec. 2, 2002

Hi all, I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help. This first is a demo called Bleam: http://www.bluespoon.com/banjoh/ This page has a binary of the demo and source code as well. The second is an older benchmark/demo called Tirtanium: http://www.tirtanium.de/prog3d.html The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror: http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip Both display stuff on screen and will run through to the end with no crashes. Justin Chevrier PS. Great work guys! _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

W->A calling and 32->16 calling
by Rolf Kalbermatter Dec. 2, 2002

Dec. 2, 2002

While going through the shell32 sources I found several issues with respect of this and at least one of them I couldn't find in the Janitorial list. ExtractIconW calls ExtractIconA which is mentioned but ExtractIconA calls InternalExtractIcon16 which is a 16 bit undocumented but exported function. I guess this should also go into the 32->16bit list somehow. I have worked on some fix for this but have to admit that this seems a little bit tricky. InternalExtractIcon16 also tries to open the file name with LoadLibrary16 so if it is a 16bit DLL the requested icons will still be extracted. PrivateExtractIcon and friends which are similar but also can handle negative icon indices which indicates that it should be treated as icon identifier, do as far as I can see not deal with 16bit libraries (they ultimatively call ICO_ExtractIconExW. This of course poses the question if the 32bit function ExtractIcon is supposed to return icons for 16bit libraries and if so, ExtractIconEx may actually also be required to do so. Below is a first attempt for a patch which does most probably not try to load resources from 16bit libraries yet. Also how about going with InternalExtractIcon16? Any comments to this? Rolf Kalbermatter Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.108 diff -u -r1.108 shell32_main.c --- dlls/shell32/shell32_main.c 21 Nov 2002 23:56:42 -0000 1.108 +++ dlls/shell32/shell32_main.c 2 Dec 2002 20:43:23 -0000 @@ -544,19 +544,18 @@ * FIXME * if the filename is not a file return 1 */ -HICON WINAPI ExtractIconA( HINSTANCE hInstance, LPCSTR lpszExeFileName, - UINT nIconIndex ) -{ HGLOBAL16 handle = InternalExtractIcon16(HINSTANCE_16(hInstance),lpszExeFileName,nIconIndex, 1); - TRACE("\n"); - if( handle ) - { - HICON16* ptr = (HICON16*)GlobalLock16(handle); - HICON16 hIcon = *ptr; - - GlobalFree16(handle); - return HICON_32(hIcon); - } - return 0; +HICON WINAPI ExtractIconA(HINSTANCE hInstance, LPCSTR lpszFile, UINT nIconIndex) +{ + HICON ret; + INT len = MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, NULL, 0); + LPWSTR lpwstrFile = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + + TRACE("%p %s %d\n", hInstance, lpszFile, nIconIndex); + + MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, lpwstrFile, len); + ExtractIconW(hInstance, lpwstrFile, nIconIndex); + HeapFree(GetProcessHeap(), 0, lpwstrFile); + return ret; } /************************************************************************* @@ -564,18 +563,21 @@ * * FIXME: if the filename is not a file return 1 */ -HICON WINAPI ExtractIconW( HINSTANCE hInstance, LPCWSTR lpszExeFileName, - UINT nIconIndex ) -{ LPSTR exefn; - HICON ret; - TRACE("\n"); +HICON WINAPI ExtractIconW(HINSTANCE hInstance, LPCWSTR lpszFile, UINT nIconIndex) +{ + HICON hIcon = NULL; + + TRACE("(%p %s %d\n", hInstance, debugstr_w(lpszFile), nIconIndex); - exefn = HEAP_strdupWtoA(GetProcessHeap(),0,lpszExeFileName); - ret = ExtractIconA(hInstance,exefn,nIconIndex); + if (nIconIndex == -1) + return (HICON) PrivateExtractIconsW(lpszFile, -1, 0, 0, NULL, 0, 0, 0); - HeapFree(GetProcessHeap(),0,exefn); - return ret; + ExtractIconExW (lpszFile, nIconIndex, &hIcon, NULL, 1); + if (hIcon) + return hIcon; + return (HICON)1; } + typedef struct { LPCSTR szApp;

1 0

Re: Wine 0.9 TODO v0.6
by Hetz Ben-Hamo Dec. 2, 2002

Dec. 2, 2002

> As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment I looked at the screenshots. Looks very impressive but very problematic.. Why problematic? simple: most of those applications requires many tweaks to run. Example: try to install Office 2k on the latest wineHQ. You'll have lots of problems installing it, and even if you install, you'll need to do "reboot" - which is not available unless you have CrossOver office. Same goes to many applications which have screenshots there.... So think what will happend if users will download wine-snapshot and won't be able to install the apps that appears in the screenshots? lots of anger, flames, false bug reports, you name it ;) Thanks, Hetz

2 1

Re: Cabinet update
by Alexandre Julliard Dec. 2, 2002

Dec. 2, 2002

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Winelib - MFC application
by Ronald MALLET Dec. 2, 2002

Dec. 2, 2002

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

3 3

RE: strcat+strcat+strcat == baaad
by Medland, Bill Dec. 2, 2002

Dec. 2, 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. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

3 2

How to fix display errors?
by Ferenc Wagner Dec. 2, 2002

Dec. 2, 2002

Hello, I decided to forward a previous post of mine from the users' newsgroup, since I got no answers there, and consider this a developer question: I'd like to correct some bugs. Having read the Developers' Guide didn't help me much: the relevant topic was empty (the program runs, but shows some errors). Perhaps you can point me in the right direction (I mean: source file in the tree)? Below is the article. See a screenshot at http://afavant.elte.hu/~wferi/wine.png (25K). It exhibits several slight problems. 1. The scrollable list has no border (Suchanfrage window, above the Phrasensuche checkbox). 2. The text input field (with Goethe in it) has no border, too. 3. The "Minimize" button is misplaced: clicking to the right of it invokes its action, the button itself is not clickable. 4. The little toolbar window to the right looks strange, but what is worse, it is sticky: appears on every viewport (It's not managed by fvwm2, like the main window.) The Suchanfrage subwindow is not sticky. While executing the program, I get the following messages: err:toolbar:ToolbarWindowProc unknown msg 0465 wp=0000004c lp=412c1d70 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:statusbar:StatusWindowProc unknown msg 0486 wp=0000 lp=00000000 err:toolbar:ToolbarWindowProc unknown msg 0486 wp=00000000 lp=00000000 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub Is there anything I can do about the above (cosmetic) errors? I use a recent CVS checkout (Wine 20021125), and I know C programming, but have no experience with graphics and Windows. Feri.

1 0

Winelib - MFC application
by jaymz＠free.fr Dec. 2, 2002

Dec. 2, 2002

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

1 0

Screenshots v0.1
by Brian Vincent Dec. 2, 2002

Dec. 2, 2002

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here: http://www.theshell.com/~vinn/ss/preview.html Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money. Random notes: - there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it - you can find all of the screenshots at: http://www.theshell.com/~vinn/ss - the images predominantly are PNG, though there are quite a few JPEGs. No GIF. - Special thanks to: Thomas Wickline Carlos Lozano David Buchmann Guido Grazioli Ender Juliasz Gonera Michael Krasucki Mike Hearn Rick Romero Robert Shade Rory King Tony Lambregts tavis Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those. Also, a few weeks ago there was a lot of discussion of a new WineHQ site. Any progress on that front? -Brian Vincent

3 2

RE: strcat+strcat+strcat == baaad
by Patrik Stridvall Dec. 2, 2002

Dec. 2, 2002

> 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? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

1 0

Adding support for xxx_test.exe all
by Francois Gouget Dec. 2, 2002

Dec. 2, 2002

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

2 2

Wine/FF7 midi help request
by Robotech_Master Dec. 2, 2002

Dec. 2, 2002

On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a discussion about midi in WINE in which FF7 was mentioned): > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > modification to wine at all, and the OSS emulation of ALSA makes the > thing transparent to WINE. Can you, or someone, please let me know how to set up wine to use this? I'm running Debian Linux; these are the versions of timidity and wine that I have: ii timidity 2.11.2-1.3 Software-only MIDI sequencer. ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a Soundblaster live card. On the FF7 config program, it gives me the choices Wine OSS midi out (#0) - disabled EMU10K1 midi Under "midi data" it gives me the choises General midi Soundfont midi (Creative AWE32/AWE64) Yamaha XG midi No matter what I try, in whatever combination, I get "Error opening device" and the wine console says fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ab930,0001003c,3):stub Can someone help me out--or point me at somewhere else I can find help? Thanks. -- Chris Meadows aka | Co-moderator, rec.toys.transformers.moderated Robotech_Master | Homepage: <URL:http://www.eyrie.org/~robotech/> robotech(a)eyrie.org | And now I've started a weblog: | http://robotech_master.livejournal.com

1 0

Wine REALLY emulates Windows (was: Texture corruption in Wine)
by David D. Hagood Dec. 1, 2002

Dec. 1, 2002

I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole "Just re-install it, it will fix it" thing down pat! 8^> To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows "mysterious changes" thing down pat! But it works. As Bugs Bunny said, "I don't ask questions, I just have fun." So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it....

1 0

DIB engine
by Johan Gill Dec. 1, 2002

Dec. 1, 2002

Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, johane(a)lysator.liu.se

3 2

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > > That solves the libc problem however compiling with -flong-int also > > means that it will be impossible to call other libraries, which > > means that it will be a little hard to use Unix specific library > > to have extra functionallity under Unix. > > But those apps will be aware of the issue, and can use explicit types, > just like we're going to do in Wine. Sure, they will not be able to > use the header files directly (actually, they might by having some > compat files that are not compiled with said flag on), but I don't > think it's a big deal anyway. It's workable, A better solution would be to port the source code to the LP64 model. It is entirely possible for to support all of LP32 (Win32 and "Unix32"), LLP64 (Win64) and LP64 ("Unix64") in a sane way. I don't think it is worth the effort to support LLP64 beyond having a "-flong-int" flag to get a working version to show as a prototype that porting is indeed possible. > and Win64 will not > bother us for some time... True. Microsoft doesn't seems that eager pushing Win64 either...

1 0

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> On December 1, 2002 11:36 am, Patrik Stridvall wrote: > > So that is why we "never" will support 100% Win64 source > compatibillity > > on 64bit platforms. We can (and presumably) will support a > LP64 variant > > of Win64 but it won't be 100% source compatible. > > I don't think it's nearly as bad as you make it. In the Wine sources, > we'll just use explicit types that don't depend of compiler switches, > while Winelib apps will just use the -flong-int flag, and get > what they > expect. Of course, they'll have to use our msvcrt lib instead of the > native libc, but that's largely true today anyway (for > different reasons). That solves the libc problem however compiling with -flong-int also means that it will be impossible to call other libraries, which means that it will be a little hard to use Unix specific library to have extra functionallity under Unix. But sure having a -flong-int flags is nice but it doesn't solve all problems. Perhaps would be good to push for its addition even now, it might take a few years before standard GNU C installation supports it.

2 1

"not enough space in GDI heap" / forking vstlib programs
by Kjetil S. Matheussen Dec. 1, 2002

Dec. 1, 2002

Hello, as I just announced I'm developing a vst-server, that loads and runs windows vst plugins. But after loading and unloading a lot of plugins, I get lots of "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" errors. I understand that the cause of this error is caused by a memory leak in a windows program. However, in the vst-server, there is no way to control memory leaks in the plug-ins, as those are made by various groups and persons. So is there a way around this error. Doing a fork for each new plug-in perhaps? Is that safe? I want to do that also to avoid having a plug-in crash the vst-server. --

2 2

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> On November 29, 2002 01:43 pm, Patrik Stridvall wrote: > > On 64 bit platforms we can never get 100% Win32 source compabillity > > because of compiler problems. If fact we can't get 100% > Win64 support > > either for the same reasons so I guess Wine on 64-bit platforms will > > be some kind of pseudo mode. > > Why are you saying that? What about the current difference between the > sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags > in the great tradition of -fwchar-short? It is a little worse that that. The C programming langauge doesn't really specify the sizes of the various integer types. It it up to the ABI. In Win32 the only really problematic difference I the one you meantion above ie the size(wchar_t) problem. It can be "solved" as specified above with -fwchar-short. The price is that you can't call the C library "wchar" functions or for that matter any library functions that depend of wchar. Not that big deal though. In the Win64 ABI Microsoft in it infinity "wisdom" has choosen the type long to be 32 bit instead of 64 bit like in most (all?) Unix API on 64 bit platforms. The Microsoft Win64 choice is called LLP64. That is long long and pointers are 64 bit. The Unix64 choice is called LP64. That is long and pointers are 64 bits. So this means that if we add an option similar to -fwchar-short, say -flong-int or -flong-32bit or whatever we can call we can't call the any library on the platform since it would could ABI problems. :-) So that is why we "never" will support 100% Win64 source compatibillity on 64bit platforms. We can (and presumably) will support a LP64 variant of Win64 but it won't be 100% source compatible.

2 1

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

2 1

Fwd: Re: [putty]Winelib support + patch
by Dimitrie O. Paun Dec. 1, 2002

Dec. 1, 2002

This is a very valid question. Alexandre, do we support generating regular executables for the apps we don't necessarily need the wrapper stuff for initialization purposes? ---------- Forwarded Message ---------- Subject: Re: [putty]Winelib support + patch Date: Mon, 25 Nov 2002 10:17:18 +0000 From: Simon Tatham <anakin(a)pobox.com> To: dpaun(a)rogers.com Cc: putty(a)projects.tartarus.org "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > FYI: the way it works is that instead of compiling the app as an > executable, we generate a .so that's loaded by wine. Now, > wine is simply a one page program that loads the libraries > that the program expects (like kernel, gdi, user), and then > loads the program itself. This is required by some apps which > have C++ static initializers, which expect to be able to call > Win32 functions, and they do so before we get a chance to > initialize them, if we were to have the app load the libs. OK, I've now read the docs and I understand this a bit better now. My next awkward question is: I can see that this is necessary for some apps which have C++ static initialisers, or which load libraries that have C++ static initialisers, but why does that mean it's necessary for PuTTY? PuTTY contains no C++, and as far as I know it uses no libraries _except_ standard Win32 API ones. Surely it should be possible _for these particular applications_ to compile them as standalone binaries? Or does Winelib currently only support doing things the inconvenient way? Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the <anakin(a)pobox.com> terminally confused is only apparent to the latter." ------------------------------------------------------- -- Dimi.

3 5

Texture problems under Wine - more info
by David D. Hagood Dec. 1, 2002

Dec. 1, 2002

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

2 2

SetWindowHookEx
by steve.lustbader＠philips.com Dec. 1, 2002

Dec. 1, 2002

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

Compilation with -DSTRICT
by Thomas Wickline Dec. 1, 2002

Dec. 1, 2002

Hello, I just want to say Thank you to all the people who put work into the Compilation with -DSTRICT Tom

1 0