- wine-devel - winehq.org

Re: Unimplemented function... Cause of exception?
by Andriy Palamarchuk 27 Sep '02

27 Sep '02

--- John Coppens <jcoppens(a)usa.net> wrote: > Hello. > > I'm trying to run WinPLACE with the last wine > package. The composition part > works, but the compiler doesn't. I get: > > fixme:int:DOSVM_Int10Handler Get Font Information - > Not Supported (BH: 0x0) > wine: Unhandled exception, starting debugger... The fixme message may or may not have the relation to the exception. What does debugger say about the exception? Run "bt" (backtrace) command in the debugger window and report what you found. Also you can get more information about the cause of the crash from relay trace. See: http://www.winehq.org/docs/wine-devel/dbg-param.shtml http://www.winehq.org/fom-meta/cache/266.html Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

2 1

Where is the specfile documented nowadays?
by Bill Medland 27 Sep '02

27 Sep '02

I've just come back to WineLib after a long time and discovered that things have changed a bit. (As a result my code finds the builtin dll but complains that it loaded the so but the dll is not found; I guess it hasn't been named or something) I guess we need to update the winelib documentation and the "binary dlls" part. As I understand it the spec file format has changed significantly over the past year and half the contents go somewhere else. In particular all that seems to go in the spec file nowadays is the entrypoint and the actual functions. Can someone point me at the current documentation or is there none. Bill

4 8

dlls/xxx/xxx_main.c
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Can we please rename all these dlls/xxx/xxx_main.c to dlls/xxx/xxx.c It should be possible now, right? Should I send a patch in? -- Dimi.

2 1

[Controversial] Developper only CVS sandbox
by Lionel Ulmer 26 Sep '02

26 Sep '02

Hi all, As Dimi is not the only one that can start flames on wine-devel, let's start a new one :-) When I see the work that is starting to go on on D3D8 or even on my old D3D code, I think that it would be nice if there was some CVS 'sandbox' where Wine developper could interact on shared code without going the Alexandre round-trip. This would be much less painful than sending patches back and forth between developpers. This sandbox would be closed (ie it would be a developper only Wine tree) to NOT start another Wine fork and all development on this sandbox would be merged back in Wine when they are ready (and then would still go the Alexandre way of course). Now, what does the Wine community think about this ? If people agree, what would be the best way to handle this ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

5 5

winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 26 Sep '02

26 Sep '02

Whenever I run winedbg (or when wine runs it in response to an exception), it fails to find debug symbols. Looking at disassembled code is making my brain numb. I "export STRIP=false" before configure to ensure that the Makefile doesn't strip anything, and gdb finds everything just fine. So what am I doing wrong? The doc says winedbg should know all about this, and I see examples of people's winedbg runs on the internet where winedbg is automagically loading tons of symbols for them (I only seem to get libntdll.dll.so working). Here's a typical run: wine: Unhandled exception, starting debugger... WineDbg starting on pid 8078e48 No debug information in ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000b0a0 Loaded debug information from ELF '/usr/local/lib/libntdll.dll.so' (0x4002e000) No debug information in ELF '/usr/local/lib/libwine.so' (0x40161000) No debug information in ELF '/usr/local/lib/libwine_unicode.so' (0x4017a000) No debug information in ELF '/lib/libm.so.6' (0x40244000) No debug information in ELF '/lib/libc.so.6' (0x40268000) No debug information in ELF '/lib/libdl.so.2' (0x403a3000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in ELF '/usr/local/lib/wine/kernel32.dll.so' (0x406e3000) No debug information in ELF '/usr/local/lib/wine/user32.dll.so' (0x407a1000) No debug information in ELF '/usr/local/lib/wine/gdi32.dll.so' (0x40909000) . . . Wine-dbg>step Single stepping until exit from function, which has no line number information. First chance exception: c0000025 in 32-bit code (0x4010b7ee). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:4010b7ee ESP:406caa70 EBP:406cab10 EFLAGS:00000246( - 00 I Z- -P1 ) EAX:406caaac EBX:40148e70 ECX:406ca754 EDX:00000000 ESI:406d0ca4 EDI:406cab1c Stack dump: 0x406caa70 (NTDLL.DLL.memcpy+0x3e1060): 406d0c9c 406cab20 406cab00 71188dc9 0x406caa80 (NTDLL.DLL.memcpy+0x3e1070): 4010b0f4 403b0814 00000000 406caa9c 0x406caa90 (NTDLL.DLL.memcpy+0x3e1080): 400c0f27 402786da 40273548 4026b208 0x406caaa0 (NTDLL.DLL.memcpy+0x3e1090): 401793e0 00000002 00000000 c0000025 0x406caab0 (NTDLL.DLL.memcpy+0x3e10a0): 00000001 406cae7c 40007f5e 00000000 0x406caac0 (NTDLL.DLL.memcpy+0x3e10b0): 40309451 016cab74 00000000 406cab20 0x406caad0 (NTDLL.DLL.memcpy+0x3e10c0): 0011: sel=008f base=4015f140 limit=00000fff 32-bit rw- Backtrace: =>0 0x4010b7ee (EXC_RtlRaiseException+0x28a in libntdll.dll.so) (ebp=406cab10) 1 0x40121c29 (NTDLL.DLL.__wine_call_from_32_regs+0xb5 in libntdll.dll.so) (ebp=406cae6c) 2 0x4010b55d (NTDLL.DLL.RtlRaiseException+0x5 in libntdll.dll.so) (ebp=406caed0) 3 0x499cd236 (URLMON.DLL.CopyBindInfo in urlmon.dll.so) (ebp=406caee0) 4 0x71119951 (BROWSEUI.DLL.EntryPoint+0x955 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406caf04) 5 0x711198fd (BROWSEUI.DLL.EntryPoint+0x901 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406cbf74) 6 0x7111988d (BROWSEUI.DLL.EntryPoint+0x891 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfcc) 7 0x7112ac78 (BROWSEUI.DLL.DllGetClassObject+0x2471 in C:\WINDOWS\SYSTEM\BROWSEUI.DLL) (ebp=406ccfec) . . ( several winedbg commands snipped here ) . 0x499cd051 (URLMON.DLL..data+0xb051 in urlmon.dll.so): subl $4,%esp Wine-dbg>symbolfile /usr/local/lib/wine/urlmon.dll.so Reading symbols from file /usr/local/lib/wine/urlmon.dll.so Wine-dbg>list Enter path to file '': Wine-dbg>step Single stepping until exit from function, which has no line number information. . . . Whatever I do, even if winedbg makes a show of loading my symbols, it never seems to synch up with my source files, except maybe for libntdll.dll.so... anyone got ideas? Thanks, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1

Re: [patch] Listview error handling
by Dimitrie O. Paun 26 Sep '02

26 Sep '02

On September 26, 2002 12:56 pm, Paul Rupe wrote: > This fixes a problem in my previous listview patch reported by Rein Klazes. > > Changelog: > Paul Rupe <prupe(a)myrealbox.com> > Remove freed sublist on failure in LISTVIEW_InsertItemT > + HDPA hdpaSubItems = NULL; I don't understand what you want to do. Why is this needed? Why did you change the code in the first place? -- Dimi.

1 0

Re: wine/dlls/comctl32 listview.c
by Rein Klazes 26 Sep '02

26 Sep '02

On Tue, 24 Sep 2002 22:20:02 -0500, you wrote: > ChangeSet ID: 5531 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/09/24 22:20:02 > > Modified files: > dlls/comctl32 : listview.c > > Log message: > Paul Rupe <prupe(a)myrealbox.com> > - Initialize memory to prevent crashes when -debugmsg +listview is on. > - Fix various array bounds related errors. > > Patch: http://cvs.winehq.com/patch.py?id=5531 This part causes trouble here: | @@ -6591,11 +6599,6 @@ | is_sorted = (lStyle & (LVS_SORTASCENDING | LVS_SORTDESCENDING)) && | !(lStyle & LVS_OWNERDRAWFIXED) && (LPSTR_TEXTCALLBACKW != lpLVItem->pszText); | | - nItem = DPA_InsertPtr( infoPtr->hdpaItems, | - is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | - hdpaSubItems ); | - if (nItem == -1) goto fail; | - | if (!LISTVIEW_SetItemT(infoPtr, lpLVItem, isW)) goto fail; | | /* if we're sorted, sort the list, and update the index */ | @@ -6606,6 +6609,14 @@ | if (nItem == -1) goto fail; | } | | + /* Add the subitem list to the items array. Do this last in case we go to | + * fail during the above. | + */ | + nItem = DPA_InsertPtr( infoPtr->hdpaItems, | + is_sorted ? GETITEMCOUNT( infoPtr ) + 1 : lpLVItem->iItem, | + hdpaSubItems ); | + if (nItem == -1) goto fail; | + | (before there were no failed calls and the list is not sorted) I did not look very hard at the cause, but it looks that LISTVIEW_SetItemT() depends on the inserted subitems in function set_main_item. Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 2

RFC: Wine and PAM integration
by Andriy Palamarchuk 26 Sep '02

26 Sep '02

I played a couple of days with PAM (Pluggable Authentication Modules). I do not have big experience in this area and want to know your opinion about my ideas. *** PAM short explanation *** PAM <From PAM for Linux documentation> Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users. It is possible to switch between the authentication mechanism(s) without (rewriting and) recompiling a PAM-aware application. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves. </From PAM for Linux documentation> PAM-aware application requests authorization using predefined id - PAM service name. System administrator configures the application authorization bas PAM service name identifies set of authorization parameters. For more information see http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ Note, that application does not see parameters of the authorization process, e.g password, Windows NT domain name, authorization server. The application only knows user name and service name. *** PAM and Wine *** Integration with PAM allows Wine to provide authentication services for Windows applications through Windows API. PAM has modules for native Unix authentication, Samba, flat files, relational databases. Example: Windows ftp server application, running under Wine can be configured to use any method of authorization, provided by PAM - Windows domain, flat file, relational database. This authorization can be made different from the authorization, required to run wine itself and different from default authorization for Wine applications. Following PAM services can be configured for Wine from more general to more detailed: * PAM service for Wine itself * Default Wine Applications service - default service which provides authentication for Windows applications. Exact name of the service will be specified in the Wine configuration is used if not specified. * Application-Specific Service Name specified in the AppDefaults section of the .wine/config file for given application. Default Application service is used if not specified Questions, problems: Do we have requirement for wineserver to work across user boundaries? If no, then we probably don't need PAM service for Wine itself. As you see Wine won't know anything about NT domains. I was thinking about passing service name through domain name parameter. Example: Call LogonUser accepts lpszDomain parameter. Instead of the domain name DOMAIN1 user provides to the application PAM service name SERVICE1. PAM service SERVICE1 is configured to use Samba module for authentication in NT domain DOMAIN1. PAM provides authorization and nothing else. To get more information from the authorization provider you should access it directly. E.g. with PAM only it is impossible to get list of users, groups from Windows NT domain, which user belongs to which group. Even more, it is impossible to know that some PAM service underneath uses NT domain and name of this domain. I can't imagine how to implement with PAM scenario like this - Windows application gets list of users belonging to some group, presents it to the user, then does authentication for one of user names. On other hand it is possible to do that with Samba. It seems it is better to ingegrate Wine with each protocol individually - implement PAM-like architecture inside Wine, but this architecture will provide much more information to Wine. The downside - this is much more complex approach than PAM. Andriy __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

3 9

Modal VB-Dialog hangs
by Fabian Cenedese 26 Sep '02

26 Sep '02

Hi I have a problem with a VB6 app. It opens a second dialog with modal flag. After this everything hangs (WaitForMultipleObject), all windows in wine are frozen. I tried to debug it, I also read the tips and hints in the FAQ for frozen programs but I still don't get it. Would be great if anybody more wise :) could have a short look at it. I made a simple testproggy, available here (project and exe): http://www.indel.ch/ftp/vbmodtest.zip I was testing with wine-20020904 with SuSE 8.0 (2.4.18) Thanks Fabi

3 4

RE: [Controversial] Developper only CVS sandbox
by Patrik Stridvall 26 Sep '02

26 Sep '02

> As Dimi is not the only one that can start flames on > wine-devel, let's start > a new one :-) Unfortunately your topic is not controversial enough. :-) > When I see the work that is starting to go on on D3D8 or even > on my old D3D > code, I think that it would be nice if there was some CVS > 'sandbox' where > Wine developper could interact on shared code without going > the Alexandre > round-trip. This would be much less painful than sending > patches back and > forth between developpers. Makes sense. > This sandbox would be closed (ie it would be a developper > only Wine tree) to > NOT start another Wine fork and all development on this > sandbox would be > merged back in Wine when they are ready (and then would still go the > Alexandre way of course). > > Now, what does the Wine community think about this ? If > people agree, what > would be the best way to handle this ? Obviously anybody that have the resources can setup a CVS server and give accounts to others. So why discuss it at all. Do it yourself or if you lack the resources try to convice somebody that do to host it for you. If people think it is a good idea they will use it and if they want write access they will ask you for an CVS account. If not, well, I think you will notice the lack of intrest... :-) In short: Action speaks louder than words. BTW, Wine already have a SourceForge account http://sourceforge.net/projects/wine/ (registered by Dimitrie it seems). Why not use it? SourceForge provides CVS access IIRC.

6 8

re: d3d8header patch
by Ann and Jason Edmeades 26 Sep '02

26 Sep '02

Hi, Just fyi, according to the msdn: http://msdn.microsoft.com/library/en-us/dx8_c/directx_cpp/Graphics/Reference /CPP/D3DX/Interfaces/ID3DXFont/ID3DXFont.asp It would appear those should go in a new header d3dx8core.h. If you need to pick them up by people who include d3dx8.h, add a #include <d3dx8core.h> into d3dx8.h. This assumes we try to keep our definitions in the same location as windows... Jason

3 3

MZ_FillPSP() in dlls/winedos/module.c
by chrismorgan＠rcn.com 26 Sep '02

26 Sep '02

I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP() if(length > 126) { ERR("Command line truncated! (length %d > maximum length 126)\n", length; length = 126; } is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126? Afaict having more than 126 characters may exceed some command.com default. Can someone shed more light on the historical reasons behind this code and whether more intelligent truncation can be performed? Thanks, Chris

4 5

Problem Saving Template with Word 2000
by Mason Kidd 25 Sep '02

25 Sep '02

Hi, I am using Word 2000 SR-1 on a fake windows install of wine 20020904. It runs fine except for one problem. When I exit the program, it tries to save the Normal.dot file to C:\windows\Application Data\Microsoft\Templates\Normal.dot and fails, with this error: The disk is full or too many files are open. (C:\windows\...\Templates\Normal.dot) If I click on Ok, and then try to save the template to a different location, even on a different partition, it gives the same error. I see this error in my xterm: err:shell:SHGetFileInfoA pidl is null! Is this related? I found bug number 956 that talks about this. Is this where I should start? It would seem to me that this would be a bug that Codeweavers had already dealt with, so do any of you guys know where to point me? Thanks. Mason Kidd

2 3

rfc: 16bit USER function
by Michael Stefaniuc 25 Sep '02

25 Sep '02

Hello, i would like to move USER functions of the type $type WINAPI $function16(@args) { return $function(@args); } from windows/*.c to dlls/user/user16.c but i don't know if that's the right place to put them because there are already some dlls/user/*16.c files. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Greg Turner 25 Sep '02

25 Sep '02

hmm, somehow this failed to make it through to the list.... Trying again... ---- awesome, thanks for your input Rein! I am no unix sockets guru (nor, obviously, am I a winsock guru ;) so this is really helpful, I'll try and submit a revision to my revision (which is apparently already in wine). That explains the time value out I was seeing of 10,000! 3 hours sounded like an awfully long time to me so I probably should have guessed those were mili's :). Basically, from your advice, I see two options. One, the obvious one, which I'll implement for now, is to convert miliseconds-> <seconds,miliseconds> and be done with it. The other would be a "correct" solution that actually works -- judging by your post, just converting the arguments won't, and I'll need to learn a little bit more about wine-winsock to make it do the right thing. I'll do the easy thing, post it to patches, then look into do_block and get back to the list if I find that this is all beyond my abilities (a quite probable scenario ;) Thanks again for the hand-holding, keep it coming, please, as I may be somewhat "out of my league" here, and I don't want to screw up wine out of ignorance. -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993 Rein Klazes wrote: >On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > > > > >>+ if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { >>+ if (optlen == sizeof(time_t)) { >>+ /* Apparently WinSock will accept a shortened struct timeval. >> >> > >In Unix the arg optval points to a struct timeval, in windows to a >(32bit) int, no mystery here. The latter is the timeout in >milliseconds. Further a non-zero timeout less then 500 (msec) is taken >as 500 msec. > > > >>+ FIXME: should we do the same for SO_SNDTIMEO? */ >> >> > >Of course, its the same issue. > > > >>+ WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); >>+ tval.tv_sec = *(time_t*)optval; >>+ tval.tv_usec = 0; >> >> > >You will need to convert from milliseconds here. > > >Unfortunately this does not work (a recv timing out). The socket in >wine is non-blocking internally, any blocking will be done in the >function do_block() using a select(). SO_RCVTMO has no effect there. > >Rein. > -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

ToDo's
by Thomas Wickline 25 Sep '02

25 Sep '02

Thanks to everyone who has gave feedback on this. Here is a draft of eveything up to today. As always in need of feedback ;) Tom Wine ToDo's as of 9/25/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * ASCII function work Winsock: * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec. DirectSound: * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Sound drivers: * Alsa driver (on final 0.9 interface) Video: * Implement native codecs (RLE...) * DIB engine to do 32-bit graphics manipulation DDE: * Enhance memory management issues (interprocess sending) Wineconsole: * Add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) Native programs: * Winhelp: fix invocation thru WinHelp * Winedbg: make winedbg use dbghelp DLL File management: * Implement NT file namespace * UNC support * Allow flexibility in FS "mounting" (for example, SMB shares) TrueType fonts: * Libfontconfig support Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I Porting issues for Mingw/Cygwin/MS_VC * Better seperation of win16/32 code. * Remove/rewite win16/9x api dependancy on newer code * Remove/rewrite wineisms from code * Documentation fixes low priority items: * VxD support with dynamic loading Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

3 3

Re: ToDo's
by Steven Edwards 25 Sep '02

25 Sep '02

Eric POUECH wrote: >>Here is the status of what I have so far on the ToDo's. >>I am not sure what section to put alot of this in so I just made >>Tools , Instructions & Aspect or Component for now. >>As much feedback as possiable is welcomed . >> >> > >here's some feedback: > >Sound drivers >- Alsa driver (on final 0.9 interface) > >Video: >- implement native codecs (RLE...) > >DDE: >- enhance memory management issues (interprocess sending) > >wineconsole: >- add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) > >file management: >- implement NT file namespace >- UNC support >- allow flexibility in FS "mounting" (for example, SMB shares) >(NB: I think we should make that clearer and not keep it shadowed in the Aspect/component list) > >(native) programs: >- winhelp: fix invocation thru WinHelp >- winedbg: make winedbg use dbghelp DLL (and implement it of course) > >--8<--------- >remove the Multimedia wave audio section >SEH support has been lately enhanced, is there still known issues ? >IMO, Dwarf2 support should not be added to winedbg. use of gdb proxy should be required instead. (even if it means adding PDB support to gdb, but that'd be a better investment) > >we should make clear what the low priority items are (VxD support with dynamic loading for example) > >A+ > > I dont know if any of these are in any of the TODOs but here goes. all of these would go under porting issues for Mingw/Cygwin/MS_VC - Better seperation of win16/32 code. - remove/rewite win16/9x api dependancy on newer code - remove/rewrite wineisms from code - documentation fixes I think all of this is high priortity but I am biased =) Thanks Steven

2 2

Hand Cursor
by Gustavo Junior Alves 25 Sep '02

25 Sep '02

The "hand cursor" hotspot is in wrong position (lower-right instead in the finger). Where I find information abou how I can fix it? Thanks, Gustavo

2 1

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Rein Klazes 25 Sep '02

25 Sep '02

On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > + if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { > + if (optlen == sizeof(time_t)) { > + /* Apparently WinSock will accept a shortened struct timeval. In Unix the arg optval points to a struct timeval, in windows to a (32bit) int, no mystery here. The latter is the timeout in milliseconds. Further a non-zero timeout less then 500 (msec) is taken as 500 msec. > + FIXME: should we do the same for SO_SNDTIMEO? */ Of course, its the same issue. > + WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); > + tval.tv_sec = *(time_t*)optval; > + tval.tv_usec = 0; You will need to convert from milliseconds here. Unfortunately this does not work (a recv timing out). The socket in wine is non-blocking internally, any blocking will be done in the function do_block() using a select(). SO_RCVTMO has no effect there. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>>> Does it matter that the dll is exporting C++ classes, not straight C >>> functions? >> >>That could make things slightly more complicated, since MS and gcc use >>different name mangling systems. if you declare functions with extern "C" >>linkage you should be OK. However there are differences in how gcc and MS >>call methods on objects (and in the vtable layout etc), so in general its not >>advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >>should implement mydll.dll as a real wine dll rather than as just a stub for >>linking). > >Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib >c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app >also depends on. I'm trying to avoid turning those other dlls into winelib >dlls, since one of them uses ATL. Am I trying to do something that can't >really be done? Is it possible to make the stub dll that winelib generates I mean take the stub that _winedump_ generates and have it forward the calls >forward calls to the win32 dll (ie, give it both the gcc mangled name and the >msvc mangled name)? > >-Steve

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>> Does it matter that the dll is exporting C++ classes, not straight C >> functions? > >That could make things slightly more complicated, since MS and gcc use >different name mangling systems. if you declare functions with extern "C" >linkage you should be OK. However there are differences in how gcc and MS >call methods on objects (and in the vtable layout etc), so in general its not >advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >should implement mydll.dll as a real wine dll rather than as just a stub for >linking). Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app also depends on. I'm trying to avoid turning those other dlls into winelib dlls, since one of them uses ATL. Am I trying to do something that can't really be done? Is it possible to make the stub dll that winelib generates forward calls to the win32 dll (ie, give it both the gcc mangled name and the msvc mangled name)? -Steve

1 0

Re: d3d8 header patch.
by Dimitrie O. Paun 25 Sep '02

25 Sep '02

On September 25, 2002 09:13 am, Yong Chi wrote: > I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Excellent. But you didn't send it in the right format. Do cvs diff -u include/d3d8.h You should add diff -u to your .cvsrc file. -- Dimi.

2 1

another MZ_Exec() problem...
by chrismorgan＠rcn.com 25 Sep '02

25 Sep '02

Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. Thanks, Chris

3 2

Re: d3d8 header patch.
by Uwe Bonnes 25 Sep '02

25 Sep '02

>Hello! >I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Now again as a unified diff (diff -u), and everybody is hapy :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

how to declare COM class?
by Yong Chi 25 Sep '02

25 Sep '02

Hello! I am one of those lurkers who finally decide to write code after many attempts. I declared a COM class best I can from looking at other COM class but I am getting syntax errors. I could not find any guide/manual on COM development. Can someone help or point to a guide on COM development? Thanks in advance...

4 4

Re: Listview Large Icon (LVS_ICON) rewrite.
by Dimitrie O. Paun 25 Sep '02

25 Sep '02

On September 24, 2002 12:07 am, Guy L. Albertelli wrote: > This is a major rewrite of the LVS_ICON (large icon) code. Not everything > is working correctly yet. Known problems: > 1. Focus rectangles are left drawn incorrectly when scrolling window. I think I know what the problem is, I'll try to fix it. > 2. Background is incorrect for at least Outlook (white instead of grey). Hm, I don't have Outlook. Any pointers and/or ideas? > 3. Scrolling in Outlook is not correct. What's the problem with this one? I might be able to fix it... -- Dimi.

2 1

Re: [patch] Listview fixes
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 05:43 pm, Paul Rupe wrote: > - Initialize memory to prevent crashes when -debugmsg +listview is on > + ZeroMemory(&lvItem, sizeof(lvItem)); Guys, *Please* stop adding these ZeroMemory calls! They just hide bugs, it is almost always the wrong fix (for the listview at least). Alexandre, you can apply the patch, I'll go through the ZeroMemory one more time anyway... -- Dimi.

1 0

ToDo's
by Thomas Wickline 24 Sep '02

24 Sep '02

Hello, Here is the status of what I have so far on the ToDo's. I am not sure what section to put alot of this in so I just made Tools , Instructions & Aspect or Component for now. As much feedback as possiable is welcomed . Tom ----------------------- Wine ToDo's as of 9/24/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support * ASCII function work Winsock * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec Multimedia wave audio * Open Sound System: Support for full-duplex. Fix bugs. * Drivers for other APIs (ALSA, Esound, others). DirectSound * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Tools * wine installation process should install and configure wine * winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions * Write a proper Users Guide Introduction * Documentation updates Aspect or Component * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * VxD support * PAM (Pluggable Authentication Modules) * SEH support * Visual C++'s native COM support * Complete the SMB code (Server Message Block) * Implement WinNT file handling * Add DWARF2 support * Implement a DIB engine * Speed up PDB support * Network UNC path handling * Libfontconfig support * Create replacement of browser component (Internet Explorer/I Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

2 1

RFC: Winsock todo's
by Martin Wilck 24 Sep '02

24 Sep '02

This is a RFC for comments. I may currently be the "offical" winsock maintainer in wine, but I wrote only a very small part of the code. I invite everybody, especially the authors of the other parts of winsock, to comment on these opinions. On Son, 2002-09-22, 18.48 Thomas Wickline wrote: > Can you give me a update on winsock todo's ? > And any other todo that you are aware of .. I have received very few bug reports lately, so I guess the basic Winsock functionality is working. A few important patches went in after the latest CVS snapshot, though. In general, the Winsock implementation in wine has a few parts that look really hackish and would need substantial cleanup. IMO this applies to the async.c file in total, but maybe I am doing injustice to authors of that file. I just find the code is really hard to read. Things like the User-space callbacks in WSAAccept() are impossible to implement correctly because the Unix accept() system call doesn't support callbacks. I do not like the fact that some Winsock1 calls, in particular select(), use direct system calls instead of using related wine APIs, e.g. WaitforMultipleEvents(). Actually if you have sockets with overlapped IO this may cause havoc. Changing this seems to be an average-difficulty task, suitable for contributors with some insight into wine internals. I'd like to see this fixed before 1.0. There are quite a few stubs left in ws2_32.spec. Some of these can probably be implemented easily and would be good work for beginners or casual wine contributors looking for a simple task, e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl(). More unit tests need to be written, also a nice task for people interested in Winsock. Wine has no concept of the Winsock2 "provider" interface. All calls to these functions are either stubs or dummy functions, such as WSAEnumProtocols(). I had a patch for this, but never got it ready for prime-time. It is unrealistic to support a "real" provider interface, allowing (like Windows) to hook new protocol handlers in the network stack, but at least we should pass some realistic information to clients. Should be done for 1.0. There is no such thing as a QOS or socket group concept in wine either, but these seem to be rarely-used features -> post-1.0, if needed at all. Although I had a relevant part in implementing the asynchronous IO in winsock, I am not quite content with it because it is not really asynchronous. Alexandre is against using threads. On Linux at least, Ben LaHaise's asyncio can be expected to become part of the 2.6 kernel series, and if that happens the wine asynchronous IO functionality should be rewritten to use the asyncio API on systems that support it. (I still havent't figured out whether aio will support sockets, though). A non-winsock todo that comes to my mind is support for NT security concepts such as tokens. But that would be a big one and should probably also be postponed after 1.0 Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

Re: Edit updates
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 02:09 am, Dimitrie O. Paun wrote: > This patch is trying to bring the edit.c in line > with the other controls. There is a problem with this patch, please don't apply. -- Dimi.

1 0

Using winbind with Wine
by Martin Wilck 24 Sep '02

24 Sep '02

Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

winebootup
by Raul Dias 24 Sep '02

24 Sep '02

Hi, What happened to winebootup? >From documentation/packaging.sgml: <varlistentry><term><filename>winebootup</filename></term> <listitem> <para> Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. </para> </listitem> </varlistentry> and it not under wine's tree. Does it exist? (or ever did?) Is there something similar to handle RunOnce keys? I just want to avoid doing a duplicated work. []'s Raul Dias

2 1

Re: Correct and update executable types in PathIsExe
by Jeff Smith 24 Sep '02

24 Sep '02

I was just going by what MSDN says. Screensavers (SCR) are just like regular executables with a standard (I believe) command-line arguement interface. I really know next to nothing about SCF files. BTW, my version of Windows (95-OSR-2.1) is so old, it doesn't even have .cmd -- Jeff Smith >From: Alexandre Julliard <julliard(a)winehq.com> >To: "Jeff Smith" <whydoubt(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: Correct and update executable types in PathIsExe >Date: 23 Sep 2002 11:13:43 -0700 > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

Re: winapi update
by Alexandre Julliard 24 Sep '02

24 Sep '02

Patrik Stridvall <ps(a)leissner.se> writes: > Fixed some issues found by winapi_check. I'd prefer that we didn't add standard headers on the dll separation hacks. We don't want to give the impression that these functions are legitimate exports. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: export {Start,End}GraphicsExposures from x11drv
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fundamentally, the main purpose of a USER driver is to deal > with windowing, and as such, it needs to be able to compute > invalidated areas. It thus makes sense to for it to export > functions that let you query this information. > > The start/end interface used by x11drv makes sense, and it > looks sane enough to be exported. I disagree. Graphics exposures are a very X11 specific concept, they don't belong in the generic driver interface. This kind of change leads to the approach that we used before: do everything in USER and add a few strategically placed calls to x11drv where we really need it. That's the wrong approach, because it cannot be adapted to other drivers except by adding more and more driver calls all over USER. The new approach is to put the driver in charge as much as possible; this means a lot more work is done inside the driver functions, which in turn gives a lot more flexibility. Of course reconciling that with dll separation is not always trivial, but that's part of the fun... -- Alexandre Julliard julliard(a)winehq.com

2 9

Re: Correct and update executable types in PathIsExe
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Looking at PathIsExe, I thought PID was probably supposed to be PIF > (Program Information File). I checked MSDN, and found this was the > case. I also found two more types that need to be recognized: SCR > (SCReensaver) and SCF (Shell Command File?). .pif is clearly right, but are you sure about .scr and .scf? My version of Windows doesn't do that. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Correct and update executable types in PathIsExe
by Rolf Kalbermatter 23 Sep '02

23 Sep '02

>Jeff Smith" <whydoubt(a)hotmail.com> writes: > >> Looking at PathIsExe, I thought PID was probably supposed to be PIF >> (Program Information File). I checked MSDN, and found this was the >> case. I also found two more types that need to be recognized: SCR >> (SCReensaver) and SCF (Shell Command File?). > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. It doesn't do it always. I had it once and disabled it immediately since I use an application with its own .scf file types. When enabled it captors the scf files directly on shell level and it wasn't possible to select scf files in the file dialog anymore!!! They are really text files in the way of Ini files. It may be possible that it comes with certain versions of Internet Explorer or Active Desktop or whatever. The scf extension when enabled is linked to SHCmdFile which starts explorer.exe without command arguments and then probably passes a DDE execute command to App: Folders, Topic: AppProperties with the command [ShellFile("%1","%1",%S)]. It is therefore not a Windows executable but really a shell extension feature. SCR files really are special exes. They are usually started by the screen saver control panel or system and not by a user double click. Windows adds links to the HKR keys to execute them as executable but again this happens on the shell level and not in the kernel. The file without any arguments started should display the configuration dialog if any. For the Test case the shell calls the file with argument /S. Installation is done by calling "rundll32.exe desk.cpl,InstallScreenSaver %l". I would not recommend trying to enable scf files at all in Wine. They are certainly no executables. I have no idea how the Wine pholosophy is in terms of enabling and supporting Windows shell features in Wine itself. It seems not useful to do that other than in the internal Wine browser/explorer eventually with help of Shell32. I would believe that Windows makes those types only indirectly executable through their registry entry and the shell which can interprete and resolve them. Rolf Kalbermatter

1 0

Name Mangling in WineLib
by steve.lustbader＠philips.com 23 Sep '02

23 Sep '02

I'm building a WineLib dll in C++ that gets called by a Windows app run by wine. Is there a way to specify how exported function and class names get mangled when compiling with winelib? The Windows app expects MSVC mangled names, so it can't find the exported symbols in my dll, since the names are mangled differently. I'd like to be able to make my dll export the MSVC style names, instead of g++ names. I think spec files used to provide similar functionality, but not any more... -Steve

1 0

PE support in MZ_Exec() /winedos/module.c
by Chris Morgan 23 Sep '02

23 Sep '02

I have a .com application that is calling out to dos int21 4Bh to load and execute a program. MZ_Exec assumes this program is always going to be a dos executable and the application fails to run and complains that it is a pe executable. So I've started to try and add support for correctly handling pe executables. So far I have a patch like below but I'm thinking that a lot more needs to be done in order to fulfill the dos requirements of this function and kind of wanted some opinions on this. This compiles but I haven't tested it since the program is at work, just wanted to get some feedback. Thanks, Chris Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- dlls/winedos/module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ dlls/winedos/module.c 22 Sep 2002 03:28:00 -0000 @@ -39,6 +39,7 @@ #endif #include "windef.h" #include "wine/winbase16.h" +#include "wine/winbase.h" #include "wingdi.h" #include "winuser.h" #include "winerror.h" @@ -342,16 +343,29 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + enum binary_type binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* this may only be called from existing DOS processes * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + binType = MODULE_GetBinaryType(hFile); + if (hFile == INVALID_HANDLE_VALUE) return FALSE; switch (func) { case 0: /* load and execute */ + if(binType == BINARY_PE_EXE) + { + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, filename, NULL, NULL, FALSE, + 0, NULL, NULL, &st, &pe); + } case 1: /* load but don't execute */ { /* save current process's return SS:SP now */

4 3

Standard load address for a Win32 program (0x00400000) not available
by Per Wigren 23 Sep '02

23 Sep '02

Hi! I'm trying to run Streambox VCR, but I get this error: err:win32:do_relocations Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load 'F:\x\vcr.exe' as Win32 binary I DO have some security-patches in the kernel.. If that is the problem, what patches should I disable? Regards Per Wigren

2 2

GetCursorPos & NTCurrentTeb question
by Rick Romero 23 Sep '02

23 Sep '02

I'm trying to track down the buttonup issue for Foxpro, and I've found an inconsistency, but I can't track it down. I started with GetCursorPos. It assigns PosX to pt->x, and PosY to pt->y, then calls X11drv.GetCursorPos, and assigns the current mouse coords to pt->x and pt->y. The problem is when the button is clicked, PosX and PosY retain the original values forever: A second or so after the left button is clicked: *Input.c current GetCursorPos (490,172) && (490,172) PosX,PosY && pt->X,pt->y *Button1Mask / state 256 / 16 (button is now up) *trace:cursor:X11DRV_GetCursorPos pointer at (489,186) (Where X says the pointer is) *-userdrivercall complete- (X11) Now: (490, 172)- 489,186- PosX,PosY && pt->X,pt->y (* my traces are just printf's) Even though the values are updated, they never get reassigned to PosX and PosY. I'm not sure WHERE that's supposed to happen, nor have I been able to figure out where GetCursorPos is called from. Is it possible that the values, and GetCursorPos are dealt with INTERNAL to MS FoxPro? I also am finding that the Wine server is returning Status Pending, then Status Timeout in WaitforMultipleObjectsEX in synchro.c. This happens a couple times when FoxPro starts up, but is eventually 'broken' out of. The Status_Pending triggers a call to wait_reply() in WaitforMultipleObjectsEx which does: ret = read( NtCurrentTeb()->wait_fd[0], &reply, sizeof(reply) ); GetCursorPos is called about 180 times before ret is set. I can't seem to find any reference to NTCurrentTeb in Wine (grep -nr), even though I found mention of it in the archive. Seems like an internal OS call. I don't know what's calling GetCursorPos, I don't know where pt->x gets assigned to PosX (but that's just a side effect, the mouse moves, it's the button that's stuck), and I don't know why wait_reply is getting a STATUS_TIMEOUT. Any ideas for me? Thanks, Rick

1 0

Re: Listview updates
by Dmitry Timoshkov 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > @@ -1034,13 +1035,13 @@ > /* Update Vertical Scrollbar */ > nListHeight = infoPtr->rcList.bottom - infoPtr->rcList.top; > scrollInfo.fMask = SIF_POS; > - if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) == FALSE > + if (GetScrollInfo(infoPtr->hwndSelf, SB_VERT, &scrollInfo) Exclamation mark (!) is missing... -- Dmitry.

1 0

wininet test fails under Win2K SP3 - compiled with gcc 3.2
by Steven Edwards 23 Sep '02

23 Sep '02

$ ./wininet_test.exe http http.c:86:Starting with flags 0x10000000 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:118:HttpSendRequestA <-- http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESOLVING_NAME(10) 0119FB DC 15 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_NAME_RESOLVED(11) 0119FBC C 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0119FC48 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 119FDDC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0119FD84 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 011 9FE04 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 7728 http.c:157: Test failed: InternetQueryDataAvailable failed http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 011 9FE40 8 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 000 00000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http.c:86:Starting with flags 0x0 http.c:88:InternetOpenA <-- http.c:91:InternetOpenA --> http.c:95:InternetConnectA <-- http.c:74:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0022EB 34 4 http.c:98:InternetConnectA --> http.c:103:HttpOpenRequestA <-- http.c:74:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0022ED A4 4 http.c:109:HttpOpenRequestA --> http.c:111:HttpSendRequestA --> http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0022EBEC 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0 022EBC8 12 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000 000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0022ECD0 4 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00 000000 0 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 002 2ECB4 4 http.c:118:HttpSendRequestA <-- http.c:125:Option 0x17 -> 1 0 http.c:129:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:134:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Mon, 23 Sep 2002 06:45:41 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html http.c:139:Option 0x22 -> 1 http://www.winehq.com/about/ http.c:143:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) http.c:148:Option 0x1 -> 1 text/html http.c:151:Entery Query loop http.c:168:ReadFile -> 1 743 http.c:168:ReadFile -> 1 436 http.c:168:ReadFile -> 1 3728 http.c:168:ReadFile -> 1 644 http.c:168:ReadFile -> 1 3736 http.c:168:ReadFile -> 1 2097 http.c:168:ReadFile -> 1 403 http.c:74:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 5C 4 http.c:74:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0022ED 8C 4 http.c:176: Test failed: InternetCloseHandle failed http: 23 tests executed, 0 marked as todo, 3 failures. Administrator@PH33R /g/src/wine-dev/wine/dlls/wininet/tests $

1 0

Re: ASIO and wine
by Thomas Wickline 23 Sep '02

23 Sep '02

Tom Hibbert wrote: >On Sun, Sep 22, 2002 at 11:44:53AM -0400, Thomas Wickline wrote: > > >>Cubase will not run with wine as it need's VxD support .. >>ASIO (Audio Stream Input Output) needs Communication between >>audio software and a piece of audio hardware and this is where >>the VxD problem comes in .. >> >>Can someone here confirm this ?? >> >>Tom >> >> > > >Cubase SX is pure 32bit.. i would have thought it didnt use VxDs which >AFAIK were obseleted with win2k... > > I am not 100% sure this was only my thoughts of what would/could happen .. That is why I ask for someone else to confirm . Tom

1 0

email to webmaster@winehq.com dead?
by Andreas Schuldei 22 Sep '02

22 Sep '02

i and others have mailed to webmaster(a)winehq.com to report changes in the daily wine builds for debian. (it was about the fact that i should not read gluck.debian.org but people.debian.org in the apt/sources.list lines) that has been quite a while. i do still get mails by confused users which do not know how to fix their download of wine packages. could someone fix that, please?

1 0

Re: FD_ZERO and FD_SET problems.
by Michael Stefaniuc 22 Sep '02

22 Sep '02

Could you please resubmit it as unified diff (diff -u)? The diff's are more readable and are more robust regarding to changes in the target file. bye michael On Fri, Sep 20, 2002 at 08:10:41PM -1000, Patrick J. McNerthney wrote: > I hope I am doing this correctly. I am porting some Win32 software > using WineLib and ran into some problems with the WinSock headers, > specifically with regards to the use of FD_ZERO and FD_SET (they just > wouldn't compile at all). Attached is the patch that resolved my > problems. > > ChangeLog > Fixed if statement in __WS_FD_SET2 which did not have it's outer set > of parenthesis. > Removed parentheses around type to be cast in __WS_FD_SET macro. > Removed WS macro usage from within other macros because the WS macro > is undefined when these macros are expanded. > > Pat McNerthney > Icicle Software, Inc. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

ASIO and wine
by Tom Hibbert 22 Sep '02

22 Sep '02

Hello, I am very interested in creating a home studio system with Linux. I get 1/4 the latency i do using Windows with the same hardware.. there is more control.. etc etc.. there are many reasons why I want to do this. I would especially like to use Cubase SX. The main barrier hampering this (besides copy protection ;) is the lack of ASIO support under Wine. Secondly, timing issues, but that is easy to tweak by the user. I am wondering if there are any progects or plans to implement ASIO in Wine/WineX. If so, I would like to contribute. If not, I will have to go to university and study computer science as well as electronic music. ;) Oh, yes - i know there are a lot of quality open source audio products (Audacity, Psycle, Csound, MAX/MSP come to mind...) I am mainly interested in seeing some VST implementation on Linux because VST is a very widely used and mature base for software synthesisers and effects. I'm told the only barrier to a NATIVE VST-capable app (Yes, the code is all there in the Audacity sources AFAIK) is the porting of a library known as libvstgui... why not run this through Winelib is the next thing i am going to ask the developers of that particular product :) Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

2 2

Re: fix listview trace crash
by Dimitrie O. Paun 22 Sep '02

22 Sep '02

On September 21, 2002 02:46 am, Rein Klazes wrote: > Hi, > > With these fixes the original reason to debug disappeared as well ;-) > > dlls/comctl32/ : listview.c > Fix some crashes running with --debugmsg +listview > + ZeroMemory(&item, sizeof(item)); We shouldn't need these. In fact, they just hide bugs, and most of them are superfluous anyways. The first hunk is a good find though, I've integrated it in my patch. Alexandre, please use this one instead. ChangeLog -- Fix outputing of a text pointer in debug mode (by Rein Klazes) -- Remove a large bunch of superfluous ZeroMemory calls -- Fix couple of bugs Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.148 diff -u -r1.148 listview.c --- dlls/comctl32/listview.c 18 Sep 2002 18:29:28 -0000 1.148 +++ dlls/comctl32/listview.c 21 Sep 2002 15:08:20 -0000 @@ -337,7 +337,7 @@ wstr = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (wstr) MultiByteToWideChar(CP_ACP, 0, (LPCSTR)text, -1, wstr, len); } - TRACE(" wstr=%s\n", debugstr_w(wstr)); + TRACE(" wstr=%s\n", text == LPSTR_TEXTCALLBACKW ? "(callback)" : debugstr_w(wstr)); return wstr; } @@ -423,7 +423,7 @@ " pszText=%s, cchTextMax=%d, iImage=%d, lParam=%lx, iIndent=%d}", lpLVItem->mask, lpLVItem->iItem, lpLVItem->iSubItem, lpLVItem->state, lpLVItem->stateMask, - debugtext_tn(lpLVItem->pszText, isW, 80), + lpLVItem->mask & LVIF_TEXT ? debugtext_tn(lpLVItem->pszText, isW, 80) : 0, lpLVItem->cchTextMax, lpLVItem->iImage, lpLVItem->lParam, lpLVItem->iIndent); return buf; @@ -605,6 +605,7 @@ BOOL bReturn; item.iItem = iItem; + item.iSubItem = 0; item.mask = LVIF_PARAM; LISTVIEW_GetItemT(infoPtr, &item, TRUE, TRUE); @@ -865,7 +866,6 @@ } /* get item */ - ZeroMemory(&item, sizeof(item)); item.mask = LVIF_TEXT; item.iItem = idx; item.iSubItem = 0; @@ -1557,7 +1557,6 @@ if (adj_sel_only) return TRUE; /* set the selection on items */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_SELECTED; lvItem.stateMask = LVIS_SELECTED; for(i = lower; i <= upper; i++) @@ -1576,7 +1575,7 @@ LVITEMW lvItem; INT index, i; - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.state = 0; lvItem.stateMask = LVIS_SELECTED; remsel.lower = lower; @@ -1734,7 +1733,6 @@ INT oldFocus = infoPtr->nFocusedItem; LVITEMW lvItem; - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.state = LVIS_FOCUSED; lvItem.stateMask = LVIS_FOCUSED; LISTVIEW_SetItemState(infoPtr, nItem, &lvItem); @@ -1830,8 +1828,8 @@ if (nFirst == -1) nFirst = nItem; - item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + item.stateMask = LVIS_SELECTED; /* FIXME: this is not correct LVS_OWNERDATA * See docu for LVN_ITEMCHANGED. Is there something similar for @@ -1889,8 +1887,6 @@ POINT ptItem; RECT rcSel; - item.stateMask = LVIS_SELECTED; - if ((uView == LVS_LIST) || (uView == LVS_REPORT)) { if (infoPtr->nSelectionMark == -1) @@ -1910,6 +1906,8 @@ nFirst = nLast = -1; } + item.stateMask = LVIS_SELECTED; + for (i = 0; i <= GETITEMCOUNT(infoPtr); i++) { if (nFirst > -1) @@ -2397,8 +2395,6 @@ lpSubItem = (LISTVIEW_SUBITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_SUBITEM)); if (!lpSubItem) return FALSE; - ZeroMemory(lpSubItem, sizeof(LISTVIEW_SUBITEM)); - /* we could binary search here, if need be...*/ for (i = 1; i < hdpaSubItems->nItemCount; i++) { @@ -2692,7 +2688,6 @@ TRACE("(hdc=%x, nItem=%d)\n", hdc, nItem); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE | LVIF_INDENT; lvItem.stateMask = LVIS_SELECTED | LVIS_STATEIMAGEMASK; lvItem.iItem = nItem; @@ -2874,7 +2869,6 @@ hdc, nItem, rcItem.left, rcItem.top, rcItem.right, rcItem.bottom); /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT | LVIF_IMAGE | LVIF_STATE; lvItem.stateMask = LVIS_SELECTED | LVIS_FOCUSED; lvItem.iItem = nItem; @@ -3752,7 +3746,7 @@ /* remove it from the selection range */ - ZeroMemory(&item,sizeof(item)); + item.state = LVIS_SELECTED; item.stateMask = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr,nItem,&item); @@ -3858,10 +3852,10 @@ else { ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item,sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3873,7 +3867,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = pszText; dispInfo.item.cchTextMax = textlenT(pszText, isW); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -3940,11 +3934,10 @@ else { LVITEMW item; - ZeroMemory(&lvItemRef,sizeof(LISTVIEW_ITEM)); - ZeroMemory(&item, sizeof(item)); item.iItem = nItem; item.iSubItem = 0; item.mask = LVIF_PARAM | LVIF_STATE; + item.stateMask = ~0; ListView_GetItemW(infoPtr->hwndSelf, &item); lvItemRef.hdr.iImage = item.iImage; lvItemRef.state = item.state; @@ -3953,7 +3946,6 @@ } /* get information needed for drawing the item */ - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -3966,7 +3958,7 @@ dispInfo.item.mask = 0; dispInfo.item.iItem = nItem; dispInfo.item.state = lpItem->state; - dispInfo.item.stateMask = 0; + dispInfo.item.stateMask = 0; /* FIXME: why not copy the state mask in here? */ dispInfo.item.pszText = lvItem.pszText; dispInfo.item.cchTextMax = lstrlenW(lvItem.pszText); dispInfo.item.iImage = lpItem->hdr.iImage; @@ -4218,8 +4210,6 @@ if ((nItem >= -1) && (lpFindInfo != NULL)) { - ZeroMemory(&lvItem, sizeof(lvItem)); - if (lpFindInfo->flags & LVFI_PARAM) { lvItem.mask |= LVIF_PARAM; @@ -5131,7 +5121,6 @@ if (uView & LVS_REPORT) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_INDENT; lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -5544,9 +5533,9 @@ TRACE("(nItem=%d)\n", nItem); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.mask = LVIF_TEXT; lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.cchTextMax = DISP_TEXT_SIZE; lvItem.pszText = szDispText; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) @@ -5603,10 +5592,10 @@ if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iItem = nItem; - lvItem.stateMask = uMask; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; + lvItem.stateMask = uMask; if (LISTVIEW_GetItemW(infoPtr, &lvItem, TRUE)) uState = lvItem.state & uMask; } @@ -6352,8 +6341,6 @@ if ( !(lpItem = (LISTVIEW_ITEM *)COMCTL32_Alloc(sizeof(LISTVIEW_ITEM))) ) return -1; - ZeroMemory(lpItem, sizeof(LISTVIEW_ITEM)); - /* insert item in listview control data structure */ if ( (hdpaSubItems = DPA_Create(8)) ) nItem = DPA_InsertPtr(hdpaSubItems, 0, lpItem); @@ -6718,7 +6705,6 @@ } else { - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -6783,7 +6769,6 @@ SelectObject(hdc, old_font); /* restore the old font */ ReleaseDC(infoPtr->hwndSelf, hdc); - ZeroMemory(&lvItem, sizeof(lvItem)); lvItem.iSubItem = iCol; lvItem.mask = LVIF_TEXT; lvItem.cchTextMax = DISP_TEXT_SIZE; @@ -7190,14 +7175,13 @@ BOOL bResult = TRUE; LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s)\n", - nItem, debuglvitem_t(lpLVItem, TRUE)); + TRACE("(nItem=%d, lpLVItem=%s)\n", nItem, debuglvitem_t(lpLVItem, TRUE)); - ZeroMemory(&lvItem, sizeof(lvItem)); + lvItem.iItem = nItem; + lvItem.iSubItem = 0; lvItem.mask = LVIF_STATE; lvItem.state = lpLVItem->state; lvItem.stateMask = lpLVItem->stateMask ; - lvItem.iItem = nItem; if (nItem == -1) { @@ -7227,24 +7211,18 @@ */ static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem, BOOL isW) { - BOOL bResult = FALSE; - LVITEMW lvItem; + LVITEMW lvItem; - TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", - nItem, debuglvitem_t(lpLVItem, isW), isW); + TRACE("(nItem=%d, lpLVItem=%s, isW=%d)\n", nItem, debuglvitem_t(lpLVItem, isW), isW); - if ((nItem >= 0) && (nItem < GETITEMCOUNT(infoPtr))) - { - ZeroMemory(&lvItem, sizeof(LVITEMW)); - lvItem.mask = LVIF_TEXT; - lvItem.pszText = lpLVItem->pszText; + if ((nItem < 0) && (nItem >= GETITEMCOUNT(infoPtr))) return FALSE; + lvItem.iItem = nItem; lvItem.iSubItem = lpLVItem->iSubItem; - if(isW) bResult = ListView_SetItemW(infoPtr->hwndSelf, &lvItem); - else bResult = ListView_SetItemA(infoPtr->hwndSelf, &lvItem); - } - - return bResult; + lvItem.mask = LVIF_TEXT; + lvItem.pszText = lpLVItem->pszText; + + return LISTVIEW_SetItemT(infoPtr, &lvItem, isW); } /*** @@ -7489,7 +7467,6 @@ if (!infoPtr) return -1; SetWindowLongW(hwnd, 0, (LONG)infoPtr); - ZeroMemory(infoPtr, sizeof(LISTVIEW_INFO)); infoPtr->hwndSelf = hwnd; /* determine the type of structures to use */ @@ -8097,9 +8074,8 @@ bGroupSelect = (LISTVIEW_GetItemState(infoPtr, nItem, LVIS_SELECTED) == 0); - ZeroMemory(&item, sizeof(item)); + item.state = bGroupSelect ? LVIS_SELECTED : 0; item.stateMask = LVIS_SELECTED; - if(bGroupSelect) item.state = LVIS_SELECTED; LISTVIEW_SetItemState(infoPtr, nItem, &item); LISTVIEW_SetItemFocus(infoPtr, nItem);

2 3

Patch - stub and workaround to make wineserver compile on cygwin
by Steven Edwards 22 Sep '02

22 Sep '02

This will allow you to run wineserver on cygwin. We still lack tons of stuff before we can have a WINE that really works on Cygwin but over the next few months/years++ as I am learning, I will keep working on this. Changelog: Wineserver - Stub get/set_thread_context in wineserver so it will build/run Change permission error to a Warning when running on Windows/Cygwin Index: context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.23 diff -u -r1.23 context_i386.c --- context_i386.c 14 Aug 2002 20:59:03 -0000 1.23 +++ context_i386.c 22 Sep 2002 03:19:41 -0000 @@ -460,9 +460,24 @@ file_set_error(); } -#else /* linux || __sun__ || __FreeBSD__ */ +#elif defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +static void set_thread_context( struct thread *thread, unsigned int flags, const CONTEXT *context ) +{ + printf("get_thread_context is a stub on WINDOWS!\n"); + return 0; +} + +#else /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ #error You must implement get/set_thread_context for your platform -#endif /* linux || __sun__ || __FreeBSD__ */ +#endif /* linux || __sun__ || __FreeBSD__ || _WINDOWS */ /* copy a context structure according to the flags */ Index: request.c =================================================================== RCS file: /home/wine/wine/server/request.c,v retrieving revision 1.67 diff -u -r1.67 request.c --- request.c 16 Aug 2002 20:02:15 -0000 1.67 +++ request.c 22 Sep 2002 03:21:04 -0000 @@ -483,7 +483,11 @@ } if (!S_ISDIR(st->st_mode)) fatal_error( "%s is not a directory\n", name ); if (st->st_uid != getuid()) fatal_error( "%s is not owned by you\n", name ); +#if defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) + fprintf( stderr, "Warning: %s is accessible by other users\n", name ); +#else if (st->st_mode & 077) fatal_error( "%s must not be accessible by other users\n", name ); +#endif /* defined(__MINGW__) || defined(__CYGWIN__) || defined(_WINDOWS) */ } /* create the server directory and chdir to it */

1 0

Re: wine status page
by Brian Vincent 22 Sep '02

22 Sep '02

> that's ok. I've just uploaded your file to winehq > it's up (& running). thanx for your good work If someone wants to forward me the raw HTML I'll edit it to include WWN threads. -brian

4 4

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 22 Sep '02

22 Sep '02

One step at a time... Now I've successfully included my stubbed dll into the wine tree. When I try to link to it, however, I still get undefined references to what should be in the dll. I added my stubbed dll to the my_other_dll_DLLS section of the Makefile.in, just like it were a normal wine dll. Is that all I need to do to link to it? When I run nm on my dll in /usr/local/lib/wine, it only lists entries like: 000131a4 T __wine_stub_mydll_dll_13 It doesn't list any of the exported functions that are listed in the spec file that winedump generated. Does wine automagically match up those stub statements with the exported symbols? Does it matter that the dll is exporting C++ classes, not straight C functions? -Steve Hi Steve, > I upgraded my autoconf, which solved my first problem. Now, > everything runs fine until I get to the make install step, when > I get this error: <snip> The attached patch to winedump corrects the over-enthusiatic insertion of generated DLL entries into dlls/Makefile.in, and renames the MODULE from <dll> to <dll>.dll as per the current build process. You can manually remove the offending lines youself, edit dlls/Makefile.in and remove the 2 lines referring to your DLL after the targets "uninstall::" and "install::". Then append".dll" to the MODULE = line in dlls/<yourdll>/Makefile.in. Alternately, apply the patch and regenerate. I've just tested the process from start to finish and it works for me now. Let me know if you find any other issues. I've sent the patch to wine-patches/Alexandre. > Thanks for making those changes to the README, hopefully they'll get > committed soon so other can avoid the problems I had. np :-) Jon (See attached file: winedump_fix.diff)

2 1

Re: notepad vs write
by Sean Young 21 Sep '02

21 Sep '02

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: > > The problem is that write will handle RTF and Word documents correctly, > > while notepad is just a text editor and will only display garbage... > > > > (yes, wordpad will probably have problems with complex word documents, > > but it should work with simple ones) > > I believe that Write is able to handle only old Word 5.x/6.x format files > (and of course RTFs). RTFs should not produce too much trouble (just feed > them to a richedit control). Regarding Word 5.x format here is a snipped > from my very old DOS code which handled those files (*.doc,*.wri) well > (it completely ignores formatting though): I've written a .wri to RTF converter, which is available here: http://www.msxnet.org/word2rtf/write.c It should be almost complete. The output is almost the same as the microsoft converter (including bugs, if desired). Now I have enough information to write write32.cnv, but is there any need for this? Sean

2 2

regression in recent cvs (transparent window) ?
by T'aZ 21 Sep '02

21 Sep '02

i've recently compiled wine cvs, and now, the content of a window from an app is not shown, it's the bug http://bugs.winehq.com/show_bug.cgi?id=1033 cmorgan on irc said me i might post here so that "maybe someone knows if it was their patch that did it" :) -- T'aZ *Just because you are paranoid, it doesn't mean they are not after you.*

1 0

Re: HRGN
by Michael Stefaniuc 21 Sep '02

21 Sep '02

On Fri, Sep 20, 2002 at 05:15:10PM -0400, Dimitrie O. Paun wrote: > Oddly enough, this seem to work... STOP! It dosn't work: [...] ../../windows/painting.c:433: switch quantity not an integer [...] make[2]: *** [../../windows/painting.o] Error 1 make[2]: Leaving directory `/home/michi/work/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/home/michi/work/wine/dlls' make: *** [dlls] Error 2 You picked one of the 3 handles that dosn't even compile when switched to a void* (the other two are HICON, HINSTANCE). None of the to be converted handles are so simple to convert, because if it would have been so simple, it would have already been done ;). Before i start working on the conversion of a handle i do an automated compile run for every remaining DECLARE_OLD_HANDLE saving the output of the build. Here some statistic from a compile run from 3 days ago: camus:/scr/wine.test$ for i in wine.H*; do > echo -n "$i: " > diff -u wine/make.out $i/make.out | grep -c ^+ > done wine.HBITMAP: 664 wine.HBRUSH: 428 wine.HDC: 941 wine.HFONT: 460 wine.HICON: 163 wine.HINSTANCE: 200 wine.HKEY: 423 wine.HMENU: 322 wine.HPEN: 216 wine.HRGN: 220 As you can the there are at least 160 lines of warnings to look at. bye michael > > ChangeLog > Convert HRGN to void * > > Index: include/windef.h > =================================================================== > RCS file: /var/cvs/wine/include/windef.h,v > retrieving revision 1.74 > diff -u -r1.74 windef.h > --- include/windef.h 16 Sep 2002 22:47:05 -0000 1.74 > +++ include/windef.h 20 Sep 2002 18:25:30 -0000 > @@ -89,7 +89,7 @@ > DECLARE_HANDLE(HMONITOR); > DECLARE_HANDLE(HPALETTE); > DECLARE_OLD_HANDLE(HPEN); > -DECLARE_OLD_HANDLE(HRGN); > +DECLARE_HANDLE(HRGN); > DECLARE_HANDLE(HRSRC); > DECLARE_HANDLE(HTASK); > DECLARE_HANDLE(HWINEVENTHOOK); -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

Re: winedump doc
by Dimitrie O. Paun 21 Sep '02

21 Sep '02

On September 20, 2002 04:13 pm, Eric Pouech wrote: > this patch adds winedump documentation > (Alexandre, you can delete tools/winedump/README if you want) Sorry, but I don't agree with this patch. Unix docs for command line utilities come in the form of man pages (or info pages). Why put in .sgml? Who's gonna read it there? Who's gonna maintain it there? It should go into a file: programs/winedump/windump.man.in or similar... -- Dimi.

2 2

Re: documentation dir
by Dimitrie O. Paun 20 Sep '02

20 Sep '02

On September 18, 2002 04:10 am, Eric POUECH wrote: > IMO, most of the documentation (even the internals description, > status of DLL) should be made in the DocBook form I don't think this is right. Documenetation that is meant for the user should go into .sgml, no disagreement here. Documentation that is meant for the ongoing developement of a DLL (something like the TODO list, or a few comments on the internal structure, or some tips, etc.) should go as plain text as close as possible to the code that it's documenting. I can not stress how important that is. I find this "developer" documentation useful beyon words: as I read through the code, it gives me ideas on what to work, I keep it _updated_. On the other hand, I've never even read 50% of the .sgml documentation even once. But even if I do, it will never have the "current" status of the one embedded in the/close to the code. As I said before, this thing has been tried numerous times before, and everybody reached the conclusion that the documentation pertaining to code should be as close to the code that it's documenting (see javadoc et. Co.). -- Dimi.

3 5

Re: wine status page
by Eric Pouech 20 Sep '02

20 Sep '02

> I have a update for the status page. > I made changes to the php.html file > If you need more info just let me know Thomas that's ok. I've just uploaded your file to winehq it's up (& running). thanx for your good work A+

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 20 Sep '02

20 Sep '02

Hi Jon I upgraded my autoconf, which solved my first problem. Now, everything runs fine until I get to the make install step, when I get this error: make[2]: Leaving directory `/home/stevenlu/wine/dlls/x11drv' mydll.dll.so \ rm -f /usr/local/lib/libntdll.dll.so make[1]: mydll.dll.so: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__install__] Error 2 Winedump created dlls/mydll/mydll.so, not mydll.dll.so. Thanks for making those changes to the README, hopefully they'll get committed soon so other can avoid the problems I had. -Steve Hi Steve, On Wed, 18 Sep 2002 18:57, steve.lustbader(a)philips.com wrote: > The README section on inserting the stub dll into the wine tree > seems a little out-dated. It tells me to run autoconf, but > autoconf complains that it cannot find configure.in - is this > step still needed? Yes, any time that you add or delete directories to the base distribution you need to re-run autoconf to generate a new configure script. In your case you are running an older version of autoconf. Make sure that you are running autoconf version 2.53 or higher, or this process will not work. There was a thread a while ago on allowing earlier versions of autoconf to be used to build Wine, but its not seen as too onerous to require a recent version for developers. > If I skip autoconf (which may be causing this problem), when > I run make depend I get: <snip> Yes, you have the dll directory and a Makefile.in in there, but no Makefile, since configure didn't get updated and generate one for you. > I ran the install script that winedump produced, but maybe that's > not up-to-date with respect to the current wine build process? I updated the build process following the big changes earlier this year for building on Win32. I don't believe there are any problems, but there have been some changes since then. If you have any issues let me know and I'll try and iron them out. If I get a moment I'll update the README on requiring a new autoconf also. I was considering allowing generated DLL'd to be built out of the tree but I didn't want to be generating too many files from winebuild (and autoconf files for a whole new dll project can be quite large). Cheers, Jon

2 1

Debug info of so
by Fabian Cenedese 20 Sep '02

20 Sep '02

Hi I changed my application now from calling a Win32 dll to calling a Linux so. But of course I can't load the pdb file I have from the Windows dll. Is there something similar for Linux? How can I generate such a file and how do I tell Wine to use it? I made the so with KDEdevelop. Thanks Fabi

2 1

Call to update the 'Who's Who' page
by Jeremy Newman 20 Sep '02

20 Sep '02

It's time to update the Wine Who's Who page. http://www.winehq.com/about/index.php?who I need all current developers to send me their info for this page. It is optional to be listed here of course. If you are on the list now and do not wish be be listed let me know. I'll also take anyone's suggestions on how to improve this page. Optional info I'd like from everyone. Your name, e-mail, home page url, location, role, and bio. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

1 0

[Alsa-devel] update of "known bugs" list (forw)
by Joerg Mayer 20 Sep '02

20 Sep '02

----- Forwarded message from Takashi Iwai <tiwai(a)suse.de> ----- From: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)lists.sourceforge.net Subject: [Alsa-devel] update of "known bugs" list Date: Thu, 19 Sep 2002 17:46:58 +0200 Hi Patrick, the following is the update of known bugs list on the web. could you update the page? * OSS emulation on WINE --> works the following workaround is necessary on some cards/chips, which support only 16bit samples. you need to set the operation mode by writing a configuration onto /proc/asound/card0/pcm0p/oss, i.e. # echo "wine 0 0 direct" > /proc/asound/card0/pcm0p/oss * intel8x0 --> fixed all three entries are solved. * ice1712 --> changed DMX-6fire frontbox is partially working (no spdif yet) * via8233 --> fixed no problems now (on cvs it's merged together with via686 as snd-via82xx driver) New entries: * es1968 capture doesn't work. * ymfpci pcm playback is not audible on toshiba tecra8100. Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Alsa-devel mailing list Alsa-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

Re: get GetDateFormatW somewhat working...
by Vincent Béron 19 Sep '02

19 Sep '02

Le jeu 19/09/2002 à 17:25, Arthur L. Jones a écrit : [...] > > notes: it seems like, if this ever worked correctly, that > OLE_GetFormatA could be implemented by just copying > the ascii buffer and sending it along to OLE_GetFormatW? That's the easiest way of implementing both the W and A variant of an API. There are numerous examples of such behavior in Wine. For the patch, the preferred format is unified (diff -u). You can add a line "diff -u" in your .cvsrc to do it automatically. Vincent

1 0

Problem with redraw/initialization in the X11 driver
by Martin Cracauer 19 Sep '02

19 Sep '02

Hi, first of all let me say that I am impressed by the progress that wine made in the last months and I also see that working things don't get broken for long anymore. Congrats! I have one problem with a game and I think the problem might be easy to solve if you point me to the right piece of code. Basically the game (TacOps4) works fine, including all of OpenPlay.dll based networking, but there is a redraw problem with the X11 driver. When using the game in Wine, I see that Wine often draws white all over the main window of this application, and only parts which are redrawn manually by the game are rendered correctly. I think it is a safe guess that we see overcautious wine code in action here, initially the window to white with good intentions, but the application tries to optimize its redraw strategy and hence leaves all the white that wine draws. I tried switching on and off all the X11 driver options (dga etc.), but the problem was unaffected. The same problem appears in exactly the same way on Linux and FreeBSD. I am using XFree4.2 and the CVS version of DRI. I placed a screenshot showing the problem at http://www.cons.org/tmp/wine-tacops-problem.png You see that the main window is mostly white except for one item which I just dragged from the small window to the main window, where the game redrew just this area of the main window, and a second small area of the main window which the game engine redrew for whatever reason. Any suggestions about Wine code I should mess around with? Maybe there is explicit code which does this whitening that I could disable or make more clever? A demo of this game is available, showing the same symptoms, in can anybody wants to try it. ftp://ftp.battlefront.com/pub/demos/tacops4/tacops4demo_i.exe Mail me if you are unfamiliar with the game and want to see the bug fast, I don't want to clutter up this mail. Thanks! Martin

2 1

Replacing a DLL
by steve.lustbader＠philips.com 19 Sep '02

19 Sep '02

I have a windows app that calls LoadLibrary on all the DLLs in a certain directory. It doesn't actually call any functions in the DLL; simply loading it causes the desired effects to take place. I'd like to replace one of those DLLs with a WineLib version that calls some Linux functions. I've compiled the WineLib dll with Winemaker, so now I have mydll.dll.so. It's written in C++, by the way. How can I replace the normal mydll.dll, such that the Windows program will load the winelib dll when I run it with Wine? -Steve

1 0

win32 types documentation
by Raul Dias 19 Sep '02

19 Sep '02

Hi, I am having some difficulty into understanding some parts of wine source because of my lack of win32 knowledge. I am looking for undertanding into win32 types like WCHAR, LPWSTR, LPCWSTR and so on. I tryed to search msdn for this but I did not find any good doc about it. So, can someone point me good urls about this? thanks, Raul Dias

2 1

documentation dir
by Dimitrie O. Paun 19 Sep '02

19 Sep '02

People, While I'm waiting for wine to compile, I figured I'd start a new flamewar :P I was looking through the documentation directory, and there are a few things that shouldn't be in there IMO. We are getting closer to 1.0, and we should clean up our act, me thinks... The CVS scripts are meant to clarify what I mean, and for Alexandre to use... (hint, hint :)) And now to the constructive part: -- get rid of old, obsolete files: Script: cvs rm -f documentation/{programs,winsock} cvs ci -m "Remove obsolete docs" documentation -- remove WineHQ stuff out of there There are other things that are on WineHQ, and they don't reside in there. Why do we keep stuff like db2html-winehq in there? If we _need_ it in there, it should be in tools/ but I don't see patch.py anywhere in the tree, and that one is used on WineHQ, so I suggest we keep all WineHQ things in one place (and outside the wine tree) Script: cvs rm -f documentation/{db2html-winehq,make_winehq} cvs ci -m "Remove WineHQ stuff" documentation -- rename installation-und-konfiguration.german We have already a README.fr, we should be consistent. Script: cp installation-und-konfiguration.german README.de cvs rm -f documentation/installation-und-konfiguration.german cvs add documentation/README.de cvs ci -m "Rename installation-und-konfiguration.german to README.de" documentation -- what's up with HOWTO-winelib? If it's already in .sgml, we should delete it. Else, we should integrate in the Winelib guide, and delete it. Anyone knows the its status? -- why do we have psdrv.reg in documentation? Shouldn't it be with the other conf files? -- documentation/shell32 should be moved as a README in the dlls/shell32 Script: cp documentation/shell32 dlls/shell32/README cvs rm -f documentation/shell32 cvs add dlls/shell32/README cvs ci -m "Rename documentation/shell32 to dlls/shell32/README" documentation dlls/shell32 -- what's up with wine.texinfo? Is it still maintained? Shouldn't we incorporate whatever is in there in the .sgml, and get rid of it? Anyone knows the its status? -- why do we have config files in documentation/samples? Shouldn't we move documentation/samples to to something like conf/ or etc/? -- the documentation/status idea was mine, but I now think it was misguided The information stays buried in there, and no one maintains it. We should salvage what's still good, and move it in a README file in the appropriate dll directory, or even directly in the .c file, where appropriate. Comments? -- Dimi.

4 6

.spec file format
by Gil Hauer 19 Sep '02

19 Sep '02

Hello, I've reviewed the documentation on the web site as will as some of the documents in the distribution but I cannot seem to find this information. Is there a document that describes the format of the .spec files used in the dll directories? Thanks, Gil

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 19 Sep '02

19 Sep '02

The README section on inserting the stub dll into the wine tree seems a little out-dated. It tells me to run autoconf, but autoconf complains that it cannot find configure.in - is this step still needed? If I skip autoconf (which may be causing this problem), when I run make depend I get: cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/home/stevenlu/wine/dlls' cd `dirname errh_auto/__depend__` && make depend make[2]: Entering directory `/home/stevenlu/wine/dlls/errh_auto' make[2]: *** No rule to make target `depend'. Stop. make[2]: Leaving directory `/home/stevenlu/wine/dlls/errh_auto' make[1]: *** [errh_auto/__depend__] Error 2 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__depend__] Error 2 I ran the install script that winedump produced, but maybe that's not up-to-date with respect to the current wine build process? Or am I just doing something else wrong? -Steve Jon Griffiths <jon_p_griffiths To: Steven Edwards <steven_ed4153(a)yahoo.com> @yahoo.com> cc: wine-devel(a)winehq.com Sent by: (bcc: Steve Lustbader/ANR/MS/PHILIPS) wine-devel-admin Subject: Re: WineLib and DLLs @winehq.com Classification: 09/12/2002 05:58 PM Please respond to jon_p_griffiths Hi, >I'm writing a WineLib DLL that makes calls in my own Windows DLLs >(not Wine's DLLs). I have the header files for those DLLs, and the >Windows binaries for them. How do I link to them? Do I need to wrap >them in spec files? What do I need to put into my Makefile.in? look at tools/winedump. In spec mode it will generate everything you need to link to this dll - a makefile and dummy implementation, spec file and a script to insert it into your existing WINE tree (to link with). The README gives instructions for exactly this case (and some other more advanced ones). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

Parent notifications
by Dimitrie O. Paun 19 Sep '02

19 Sep '02

I've found this in control/edit.c HWND hwndParent; /* Handle of parent for sending EN_* messages. Even if parent will change, EN_* messages should be sent to the first parent. */ Is this true for all controls? Common controls as well? Can someone with a Windows box experiment, and see what's going on? TIA, Dimi.

1 0

Re: Direct3D v8 - Try2
by Alexandre Julliard 18 Sep '02

18 Sep '02

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > I have made the above change and got it working (eventually!), and tidied up > a few other typos, functions etc. > > What is your feeling about using this as a starting point in the wine tree - > There are a number of places in the code which need work, but it would > enable others to start adding to it. Alternatively if there are any areas > you want fixed before it can go in, let me know and I'll see what I can do - > I dont fell 100% 'qualified' in this area, some of it is scrabbling around > in the manuals until I get something working! I have no problem putting it in the tree, even if it's a bit broken it's always a lot better than nothing. I'd prefer that you clean up a bit the file structure first though: you should try to group related interfaces in the same file, and cut down on the number of files, especially .h files. Anything that isn't used by multiple files should be declared static inside a single .c file. Also please don't use interface names for file names, use simpler (and lowercase) names like texture.c or buffer.c. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winaspi + libscg
by Rolf Kalbermatter 18 Sep '02

18 Sep '02

>>I'm working on a rewrite of the winaspi module, using Joerg Schilling's >>libscg. (libscg is a scsi transport library, with support of many platforms, >>cdrecord, cdrdao uses it). I'm nearly finished, but I could test only >>winaspi32 (with nero and isobuster), I need a software that uses the 16 bit >>aspi interface to test it. Anyone knows such a software that uses wnaspi.dll? > >I don't think you will find too many of this type (16 bit software using >aspi) due to the fact that the aspi interface is newer than the 32 bit api. I'm not exactly sure about the historical timeframe but ASPI was quite early available for Win 3.1. At that time it was an Adaptec user space DLL calling into their low level driver. With Windows NT a 32 bit variant was released but I'm not sure if that was initially from Adaptec or MS, reusing most of the API definitions created by Adaptec safe from some 16 bit<->32 bit differences. However as the ASPI interface for Win 3.1 was indeed a proprietary solution few other manufacturers felt compelled to support it and consequently few applications safe from the Adaptec utilities made real use of it. But most standdard applications really just went through the BIOS in Win 3.1 for drive access. I do have somewhere an old Win 3.1 installation on a old HD which I could try to dust of and there were a few smaller applications from Adaptec such as a SCSI bus probe which made use of it. However it may be quite possible that you won't get them running on a modern system even before it tries to access Winaspi. Rolf Kalbermatter

1 0

An attempt at LogonUser()
by Martin Wilck 18 Sep '02

18 Sep '02

[ This goes to wine-devel too - demonstrates PAM interface ] Patch: LogonUser.diff Against: CVS 2002-09-18 Modified files: wine: configure configure.ac wine/dlls/advapi32: Makefile.in advapi.c advapi32.spec wine/include: config.h.in winbase.h Log Message: Attempt to code LogonUser() using an interface between Wine and the PAM library. Normally, this will validate Unix username/password pairs. If PAM is suitably configured (for using winbind), usernames and passwords can be obtained from a Windows Domain controller. It is even possible for system administrators to setup a special authorization scheme for wine by editing "/etc/pam.d/wine". Status: Compiles, simple (non-unicode) test program authenticates sucessfully against Unix and Windows PDC accounts (and fails with wrong password). Fixmes: ** LogonUserW() is untested, and I have little experience with ** Unicode transformations in wine. Be prepared for bugs there. The LICENSE of PAM is rather unclear - on http://sourceforge.net/projects/pam it says "BSD License, GNU General Public License (GPL)". But I expect no problem with Wine linking against it. The flags to LogonUser() are ignored, and the resulting Token is meaningless because wine currently has no concept of security tokens. To make this really useful, more support for security issues needs to be implemented - but this function is (almost) sufficient for me :-) There are no security checks on the parameters (are they null-terminated?), because I'm not sure how to do that (enforce maximum length? If yes, which?). Perhaps the code should have gone into security.c rather than advapi.c. Or does the whole stuff belong somewhere in ntdll? Index: configure =================================================================== RCS file: /home/wine/wine/configure,v [ *** Deleted for better readability *** ] diff -u -r1.340 configure Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.77 diff -u -r1.77 configure.ac --- configure.ac 13 Sep 2002 17:54:27 -0000 1.77 +++ configure.ac 18 Sep 2002 19:00:29 -0000 @@ -613,6 +613,13 @@ [AUDIOIOLIBS="-laudioio" AC_DEFINE(HAVE_LIBAUDIOIO, 1, [Define if you have libaudioIO])])]) +dnl **** Check for PAM **** +AC_SUBST(PAMLIBS,"") +AC_CHECK_HEADERS(security/pam_appl.h, + [AC_CHECK_LIB(pam,pam_start, + [AC_DEFINE(HAVE_PAM,1,[Define if you have PAM including devel headers]) + PAMLIBS="-lpam"],,)]) + dnl **** Check for broken glibc mmap64 **** AC_CACHE_CHECK( [whether mmap64 works defined as mmap], ac_cv_mmap64_works, Index: dlls/advapi32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/advapi32/Makefile.in,v retrieving revision 1.15 diff -u -r1.15 Makefile.in --- dlls/advapi32/Makefile.in 9 Aug 2002 01:22:40 -0000 1.15 +++ dlls/advapi32/Makefile.in 18 Sep 2002 19:00:29 -0000 @@ -5,6 +5,7 @@ VPATH = @srcdir@ MODULE = advapi32.dll IMPORTS = kernel32 ntdll +EXTRALIBS = @PAMLIBS@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: dlls/advapi32/advapi.c =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi.c,v retrieving revision 1.20 diff -u -r1.20 advapi.c --- dlls/advapi32/advapi.c 27 Aug 2002 18:30:53 -0000 1.20 +++ dlls/advapi32/advapi.c 18 Sep 2002 19:00:29 -0000 @@ -24,6 +24,10 @@ #include <errno.h> #include <stdio.h> #include <string.h> +#include <stdlib.h> +#if HAVE_PAM +#include <security/pam_appl.h> +#endif #include "winbase.h" #include "windef.h" @@ -120,4 +124,240 @@ { TRACE("stub %s (harmless)\n", debugstr_w(lpMachineName)); return TRUE; +} + +/****************************************************************************** + * Init function for advapi32 - needed to properly load the pam library. + */ +BOOL WINAPI advapi32_init ( HINSTANCE hinst, DWORD reason, LPVOID reserved ) +{ +#if HAVE_PAM +#define SONAME_LIBPAM "libpam.so" + switch(reason) + { + case DLL_PROCESS_ATTACH: + if (!wine_dlopen (SONAME_LIBPAM, RTLD_NOW|RTLD_GLOBAL, NULL, 0)) + ERR ( "error opening %s\n", SONAME_LIBPAM ); + break; + } +#endif + return TRUE; +} + +#if HAVE_PAM +/****************************************************************************** + * Helper functions for the PAM interface. + */ + +/* FIXME: These should be made configurable options, at least the separator. */ +#define WINE_PAM_SERVICE "wine" +/* This corresponds to the "winbind separator" setting in smb.conf. */ +#define WINE_WINBIND_SEPARATOR '\\' +#define PAM_FAIL(x) ((x) != PAM_SUCCESS) + +/* Placeholder for future reasonable error handling */ +static int PAM_error_to_dos ( pam_handle_t *pamh, int retcode ) +{ + if ( pamh ) + TRACE( "PAM error: %s\n", pam_strerror ( pamh, retcode ) ); + switch ( retcode ) + { + case PAM_SUCCESS: return ERROR_SUCCESS; + case PAM_AUTH_ERR: return ERROR_ACCESS_DENIED; + default: return ERROR_GEN_FAILURE; + } +} + +/* The "PAM conversation callback" for LogonUser(). */ +static int PAM_logon_user_conv ( int nmsg, const struct pam_message **msg, + struct pam_response **resp, void *ptr ) +{ + int i; + struct pam_response *myresp; + + /* PAM will free myresp and the response buffers when done. */ + myresp = malloc ( nmsg * sizeof (struct pam_response) ); + if (!myresp) return PAM_BUF_ERR; + memset ( myresp, 0, nmsg * sizeof (struct pam_response) ); + + /* Fill in our password as "response" to the prompt we never show. */ + for (i = 0; i < nmsg; i++) + { + if ( msg[i]->msg_style == PAM_PROMPT_ECHO_OFF ) + { + myresp[i].resp = strdup (ptr); + break; + } + } + *resp = myresp; + return PAM_SUCCESS; +} +/******************************************************************************/ +#endif /* HAVE_PAM */ + + +/****************************************************************************** + * LogonUserA [ADVAPI32.@] + * + * PARAMS + * lpUserName : (IN) user name + * lpDomain : (IN) domain name (will only work with PAM winbind support) + * lpPassword : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserA( LPSTR lpUserName, LPSTR lpDomain, LPSTR lpPassword, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + + int err = ERROR_NOT_SUPPORTED, ret; + char *user = NULL; + struct pam_conv conv = { PAM_logon_user_conv, NULL }; + pam_handle_t *pamh = NULL; + + TRACE( "user %s, domain %s\n", lpUserName, lpDomain ); + FIXME( "ignoring type (%lx) and provider (%lx), returned token handle will be bogus!\n", + dwLogonType, dwLogonProvider ); + + if ( !lpUserName || !lpPassword || !phToken ) + { + err = ERROR_INVALID_PARAMETER; + goto abort; + } + + if ( !lpDomain ) + /* User name is "user@DNS-name" (UPN format), + * but we don't know how to convert DNS to NT domain name. + */ + { + char *p; + FIXME( "UPN format unsupported - trying unqualified name\n" ); + + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + p = strchr ( user, '@' ); + if ( p ) *p = '\0'; + } + else if ( *lpDomain == '\0' || ! strcmp ( lpDomain, "." ) ) + { + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + } + else + { + int ldom = strlen ( lpDomain ); + int lusr = strlen ( lpUserName ); + user = malloc ( ldom + lusr + 2 ); + if ( ! user ) goto outofmem; + strcpy ( user, lpDomain ); + user[ldom] = WINE_WINBIND_SEPARATOR; + strcpy ( user + ldom + 1, lpUserName ); + } + TRACE( "PAM user name: %s\n", user ); + + conv.appdata_ptr = lpPassword; + if ( PAM_FAIL( ret = pam_start ( WINE_PAM_SERVICE, user, &conv, &pamh )) ) + goto pam_error; + + if ( PAM_FAIL( ret = pam_authenticate ( pamh, PAM_SILENT ) ) ) + goto pam_error; + + pam_end ( pamh, PAM_SUCCESS ); + *phToken = 0xcafe; + free ( user ); + + TRACE( "-> logon successful\n" ); + return TRUE; + +pam_error: + err = PAM_error_to_dos ( pamh, ret ); + goto abort; + +outofmem: + err = ERROR_NOT_ENOUGH_MEMORY; + +abort: + TRACE( "-> error %x\n", err ); + if ( pamh ) pam_end ( pamh, PAM_SUCCESS ); + if ( user ) free ( user ); + SetLastError ( err ); + return FALSE; + +#endif /* HAVE_PAM */ +} + +/****************************************************************************** + * LogonUserW [ADVAPI32.@] + * + * PARAMS + * lpUserNameW : (IN) user name + * lpDomainW : (IN) domain name (will only work with PAM winbind support) + * lpPasswordW : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserW( LPWSTR lpUserNameW, LPWSTR lpDomainW, LPWSTR lpPasswordW, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + int ulen = 0, dlen = 0, plen = 0, ret; + LPSTR buf = NULL; + LPSTR lpUserName, lpPassword, lpDomain; + + if ( !lpUserNameW || !lpPasswordW || !phToken ) + { + SetLastError ( ERROR_INVALID_PARAMETER ); + return FALSE; + } + + ulen = WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, NULL, 0, NULL, NULL ); + plen = WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, NULL, 0, NULL, NULL ); + if ( lpDomainW ) + dlen = WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, NULL, 0, NULL, NULL ); + + buf = malloc ( ulen + plen + dlen ); + if ( !buf ) + { + SetLastError ( ERROR_NOT_ENOUGH_MEMORY ); + return FALSE; + } + + lpUserName = buf; + WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, lpUserName, ulen, NULL, NULL ); + + lpPassword = buf + ulen; + WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, lpPassword, plen, NULL, NULL ); + + if ( lpDomainW ) + { + lpDomain = lpPassword + plen; + WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, lpDomain, dlen, NULL, NULL ); + } + else lpDomain = NULL; + + ret = LogonUserA( lpUserName, lpDomain, lpPassword, + dwLogonType, dwLogonProvider, phToken ); + + memset ( buf, 0, ulen + plen + dlen ); + free ( buf ); + return ret; + +#endif /* HAVE_PAM */ } Index: dlls/advapi32/advapi32.spec =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v retrieving revision 1.28 diff -u -r1.28 advapi32.spec --- dlls/advapi32/advapi32.spec 6 Sep 2002 19:36:37 -0000 1.28 +++ dlls/advapi32/advapi32.spec 18 Sep 2002 19:00:29 -0000 @@ -1,3 +1,5 @@ +init advapi32_init + @ stdcall AbortSystemShutdownA(ptr) AbortSystemShutdownA @ stdcall AbortSystemShutdownW(ptr) AbortSystemShutdownW @ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) AccessCheck @@ -127,8 +129,8 @@ @ stdcall IsValidSecurityDescriptor(ptr) IsValidSecurityDescriptor @ stdcall IsValidSid(ptr) IsValidSid @ stub LockServiceDatabase -@ stub LogonUserA -@ stub LogonUserW +@ stdcall LogonUserA(ptr ptr ptr long long ptr) LogonUserA +@ stdcall LogonUserW(ptr ptr ptr long long ptr) LogonUserW @ stdcall LookupAccountNameA(str str ptr ptr ptr ptr ptr) LookupAccountNameA @ stub LookupAccountNameW @ stdcall LookupAccountSidA(ptr ptr ptr ptr ptr ptr ptr) LookupAccountSidA Index: include/config.h.in =================================================================== RCS file: /home/wine/wine/include/config.h.in,v retrieving revision 1.129 diff -u -r1.129 config.h.in --- include/config.h.in 29 Aug 2002 01:51:32 -0000 1.129 +++ include/config.h.in 18 Sep 2002 19:00:33 -0000 @@ -320,6 +320,9 @@ /* Define if you have NAS including devel headers */ #undef HAVE_NAS +/* Define if you have PAM including devel headers */ +#undef HAVE_PAM + /* Define to 1 if you have the <ncurses.h> header file. */ #undef HAVE_NCURSES_H Index: include/winbase.h =================================================================== RCS file: /home/wine/wine/include/winbase.h,v retrieving revision 1.158 diff -u -r1.158 winbase.h --- include/winbase.h 17 Sep 2002 18:54:42 -0000 1.158 +++ include/winbase.h 18 Sep 2002 19:00:33 -0000 @@ -1123,6 +1123,16 @@ #define SCS_POSIX_BINARY 4 #define SCS_OS216_BINARY 5 +/* LOGON support APIs */ +#define LOGON32_LOGON_INTERACTIVE 2 +#define LOGON32_LOGON_NETWORK 3 +#define LOGON32_LOGON_BATCH 4 +#define LOGON32_LOGON_SERVICE 5 +#define LOGON32_PROVIDER_DEFAULT 0 +#define LOGON32_PROVIDER_WINNT35 1 +#define LOGON32_PROVIDER_WINNT40 2 +#define LOGON32_PROVIDER_WINNT50 3 + BOOL WINAPI GetBinaryTypeA( LPCSTR lpApplicationName, LPDWORD lpBinaryType ); BOOL WINAPI GetBinaryTypeW( LPCWSTR lpApplicationName, LPDWORD lpBinaryType ); #define GetBinaryType WINELIB_NAME_AW(GetBinaryType) @@ -1364,6 +1374,9 @@ BOOL WINAPI ImpersonateLoggedOnUser(HANDLE); BOOL WINAPI ImpersonateSelf(SECURITY_IMPERSONATION_LEVEL); BOOL WINAPI IsProcessorFeaturePresent(DWORD); +BOOL WINAPI LogonUserA(LPSTR,LPSTR,LPSTR,DWORD,DWORD,PHANDLE); +BOOL WINAPI LogonUserW(LPWSTR,LPWSTR,LPWSTR,DWORD,DWORD,PHANDLE); +#define LogonUser WINELIB_NAME_AW(LogonUser) BOOL WINAPI LookupAccountSidA(LPCSTR,PSID,LPSTR,LPDWORD,LPSTR,LPDWORD,PSID_NAME_USE); BOOL WINAPI LookupAccountSidW(LPCWSTR,PSID,LPWSTR,LPDWORD,LPWSTR,LPDWORD,PSID_NAME_USE); #define LookupAccountSid WINELIB_NAME_AW(LookupAccountSid) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

rhlx01.fht-esslingen.de hangs in tsx11 directory
by Uwe Bonnes 18 Sep '02

18 Sep '02

Hallo Andi, a cvs update with rhlx01.fht-esslingen.de hangs in the tsx11 directory 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

winaspi + libscg
by Szombathelyi György 18 Sep '02

18 Sep '02

Hi! I'm working on a rewrite of the winaspi module, using Joerg Schilling's libscg. (libscg is a scsi transport library, with support of many platforms, cdrecord, cdrdao uses it). I'm nearly finished, but I could test only winaspi32 (with nero and isobuster), I need a software that uses the 16 bit aspi interface to test it. Anyone knows such a software that uses wnaspi.dll? Best regards, György Szombathelyi

3 2

RE: Direct3D v8
by Jesse Allen 18 Sep '02

18 Sep '02

Hi, After hearing your about your work on d3d8, I'm particularly interested in the implimentation of Direct3dCreate8. I had been working on a version of my own several weeks ago, but never had time to complete, hoping it would fix a problem with Warcraft 3's very hackish opengl mode. The game has a problem where, if it minimizes for playing movies, it forgets it's hdc -- SwapBuffers only shows (00000000) in a trace even after I restore the window. I checked out the code in x11drv for minimizing and it seems to be fine. I think the problem is in their hackish code for opengl, because even though I explicitly tell it to use opengl, it still makes a call to Direct3dCreate8 at game start before minimizing for the opening movie. Wierd. The game must be very dependent on a working d3d8.dll, no matter what. So that's the only lead there for the moment. So I'll try out that specific function and see how it works. If it looks good, I can prepare a patch for that against the current wine tree, cleaning it up where necessary. Let me know if you think if this is ok. Jesse

1 0

problems with --debugmsg -relay=this:that
by Rick Romero 18 Sep '02

18 Sep '02

I'm using Wine cvs from Monday (IIRC) I'm trying to find what appears to be a loop which that calls GetCursorPos infinately. (I know it's called repeatedly anyhow, but part of the bug is that PosX & PosY never get changed after a left click. Bug #434) Just +relay is a little too much info, so according to 'man wine': --debugmsg -relay=rtlleavecriticalsection:RtlEnterCriticalSection will turn on all relay messages except for RtlLeaveCriticalSection and RtlEnterCriticalSection. --debugmsg +relay=advapi32 will only turn on relay messages into the ADVAPI32 code. So, I tried: wine --debugmsg +cursor,+input,+mouse,-relay=kernel32:ntdll vfp.exe &> testfile2 wine --debugmsg +cursor,+input,+mouse,+relay=x11drv:gdi32:user32 vfp.exe &> testfile2 I even dropped to: wine --debugmsg +relay=x11drv:gdi32:user32 vfp.exe No relay messages. Now, just +relay works but gives too much info, so I think I've either got some syntax wrong, or maybe the(my?) man page hasn't been updated. What am I doing wrong? Thanks, Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

2 1

RFC - Closing Bug 529 - Running Perl regression tests on Windows
by Steven Edwards 18 Sep '02

18 Sep '02

I just wanted to double check that we are going to be moving away from perl for the regression test suite. If this is still true then we have one less bug for 0.9 after the existing system is changed to be C only. Thanks Steven

1 0

[OT] site down?
by Paul Millar 18 Sep '02

18 Sep '02

Hi, I can ping www.winehq.com, but can't load http://www.winehq.com/ (or any other page). Instead, I get a "connection refused" back from the local proxy. Also, email to webmaster(a)winehq.com is not being delivered (connection problems again). Looks like a server problem, so could someone give it a kick? Ta, Paul. ---- Paul Millar

3 4

Re: Right button clicks
by Fabian Cenedese 18 Sep '02

18 Sep '02

> > Does Wine support right mouse button double clicks? I have an App with > > a dialog (in fact an overridden MFC CDialog for about infos) in which I can > > double click with the right mouse button to show some additional info. But > > they never show up. After +relay tracing the messages I found that only > > WM_RBUTTONDOWN and WM_RBUTTONUP messages are generated, > > none of them get converted into clicks or even double clicks, no matter > > how fast I click. Does anyone have an idea? I now got to the real problem. The dialog's class flags include the CS_DBLCLKS in Windows, but in Wine this bit is cleared. I never explicitely wrote this flag in the source, so I guess it's MFC or Windows adding it. It works if I set it now manually but that wouldn't solve the problem in Wine. Where are the dialogs/windows created in Wine, where could this flag be added? Thanks. bye Fabi

1 0

Re: [Bug 529] - Running Perl regression tests on Windows
by Andriy Palamarchuk 18 Sep '02

18 Sep '02

> ------- Additional Comments From > Steven_Ed4153(a)yahoo.com 2002-09-17 18:50 ------- > This bug can be closed as Alexandre has said that > the regression suite will be > droping perl as no one uses it and its a bitch to > get working on Windows. Trust > me I have tried Want to let winedevel know that I'm closing the bug. Andriy Boston, MA __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Right button clicks
by Fabian Cenedese 18 Sep '02

18 Sep '02

Hi Does Wine support right mouse button double clicks? I have an App with a dialog (in fact an overridden MFC CDialog for about infos) in which I can double click with the right mouse button to show some additional info. But they never show up. After +relay tracing the messages I found that only WM_RBUTTONDOWN and WM_RBUTTONUP messages are generated, none of them get converted into clicks or even double clicks, no matter how fast I click. Does anyone have an idea? Thanks Fabi

2 3

Re: X client wrapper for Win apps?
by Alexander Gottwald 18 Sep '02

18 Sep '02

On Mon, 16 Sep 2002, Keith D. Tyler wrote: [GDI apps using X11] > This is, I realize, all probably very unrealistic dreaming, but any leads > or tips are welcome. I don't know much of the windows internals but thought of simple concept. Every Windows draw command is translated into calls to a GDI driver. this driver is either the driver of the graphics card or a printer. The people from wine already have written a driver which exports a GDI interface and maps all calls to X11. Maybe this is a starting point. I never tried to compile the wine x11drv as a native windows driver. This would be the first hurdle to take. Then one must either replace the original windows display driver or use the x11drv as proxy (export X11 and call old display driver) or even set the driver per application (create a new graphics context with the x11drv) so the rest of the system is not affected. bye ago Xpost to wine-devel, they might know it better -- Alexander.Gottwald(a)informatik.tu-chemnitz.de http://www.gotti.org ICQ: 126018723

1 0

more MSVCRT fun
by steve.lustbader＠philips.com 18 Sep '02

18 Sep '02

In my winelib app, most of the cpp files use MSVCRT only, and thanks to Martin I've gotten those to compile. A couple of my source files, however, use a mix of MSVCRT and standard glibc (fork, exec, etc). When I include unistd.h, lots of function definitions conflict with msvcrt/io.h. How can I get this mix to compile? Does the @ignore in the spec file trick from the Winelib user's guide still apply, or has it been changed (or removed altogether)? -Steve

2 1

Re: Update to REAME.fr
by Dimitrie O. Paun 17 Sep '02

17 Sep '02

> PS: are my patches inline or not? Or, can you read them easily or not? > Please answer in a private mail as to not clutter wine-devel. Yes, they are. In fact you attach them as plain/text (isn't it), but that's equivalent to inlining them, for our purposes. Thanks. -- Dimi.

1 0

Patch - Update some CVS ignores
by Steven Edwards 17 Sep '02

17 Sep '02

Changelog: Update .cvsignore's for mingw/cygwin Index: unicode/.cvsignore =================================================================== RCS file: /home/wine/wine/unicode/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- unicode/.cvsignore 25 Jul 2000 21:01:59 -0000 1.2 +++ unicode/.cvsignore 17 Sep 2002 22:20:37 -0000 @@ -1,2 +1,3 @@ Makefile libwine_unicode.so.1.0 +libwine_unicode.dll Index: tsx11/.cvsignore =================================================================== RCS file: /home/wine/wine/tsx11/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- tsx11/.cvsignore 6 Dec 2000 00:04:11 -0000 1.2 +++ tsx11/.cvsignore 17 Sep 2002 22:21:09 -0000 @@ -1,2 +1,3 @@ Makefile libwine_tsx11.so.1.0 +libwine_tsx11.dll Index: library/.cvsignore =================================================================== RCS file: /home/wine/wine/library/.cvsignore,v retrieving revision 1.2 diff -u -r1.2 .cvsignore --- library/.cvsignore 31 Oct 2000 00:20:51 -0000 1.2 +++ library/.cvsignore 17 Sep 2002 22:21:33 -0000 @@ -1,2 +1,3 @@ Makefile libwine.so.1.0 +libwine.dll

1 0

Re: Unable to print with the Wine PS driver
by Sylvain Petreolle 17 Sep '02

17 Sep '02

Same issue here with another printers. Note that the text printed in the msgboxes is random garbage. This could be uninitialised/corrupted pointer. And, last point, the 'printing' window shouldn't be there after you get these 3 windows, or at least inactive. Are you using the cvs version ? your debugger problem should be fixed now. I have to the backtrace attached at bottom. Note that calls 6 to 9 are the same I reported in 'Question about "undefined" functions' on wine-devel and they go to 0x0 access error. See http://www.winehq.com/hypermail/wine-devel/2002/09/0385.html 1 0x413c35b7 (X11DRV.DLL.SetDeviceGammaRamp+0x7b9c17 in wineps.dll.so) (ebp=405e2648) 2 0x40a1b0e0 (GDI32.DLL.StartDocA+0x80 in gdi32.dll.so) (ebp=405e267c) 3 0x403b7cb8 (notepad.exe.EntryPoint+0x1cb8 in notepad.exe.so) (ebp=405e2b24) 4 0x403b890f (notepad.exe.EntryPoint+0x290f in notepad.exe.so) (ebp=405e2b30) 5 0x403b8c35 (notepad.exe.EntryPoint+0x2c35 in notepad.exe.so) (ebp=405e2c98) 6 0x4091701f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405e2cbc) 7 0x40917093 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405e2cf4) 8 0x4091da26 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405e2d28) 9 0x408f721b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405e2d5c) 10 0x403b914a (notepad.exe.EntryPoint+0x314a in notepad.exe.so) (ebp=405e2e00) 11 0x403b60cd (notepad.exe.EntryPoint+0xcd in notepad.exe.so) (ebp=405e2e70) 12 0x400e1be6 (start_process+0x206 [process.c] in libntdll.dll.so) (ebp=405e2f28) 13 0x400e6ce0 (call_on_thread_stack+0x90 [sysdeps.c] in libntdll.dll.so) (ebp=405e2ff4) 14 0x400e6e68 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

PATCH: make wine find winelib apps better
by Martin Wilck 17 Sep '02

17 Sep '02

[ forwarded to wine-devel, potential for controversy ] Patch: open-builtin-exe Modified files: scheduler: process.c Log Message: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Winelib apps often (almost always) have mixed upper/lower case names and are therefore never found by open_builtin_exe(). Fix that, without breaking the default (all-lowercase name) for builtin apps. Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.198 diff -u -r1.198 process.c --- scheduler/process.c 27 Aug 2002 01:13:59 -0000 1.198 +++ scheduler/process.c 17 Sep 2002 16:55:18 -0000 @@ -265,11 +265,15 @@ { char exename[MAX_PATH], *p; const char *basename = get_basename(name); + void *exeptr; if (strlen(basename) >= sizeof(exename)) return NULL; strcpy( exename, basename ); for (p = exename; *p; p++) *p = FILE_tolower(*p); - return wine_dll_load_main_exe( exename, error, error_size, test_only ); + exeptr = wine_dll_load_main_exe( exename, error, error_size, test_only ); + if ( exeptr ) return exeptr; + /* If lower-case name fails, try potential mixed-case name (for Winelib) */ + return wine_dll_load_main_exe( basename, error, error_size, test_only ); } -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 4

Missing tchar.h?
by Juraj Hercek 17 Sep '02

17 Sep '02

Hi, Is tchar.h file *not installed* intentionaly? If so why? I installed september's wine snapshot. I build everything then I did "make install". File tchar.h wasn't installed. I did "make install-dev" but it didn't help (actually it was expected, since install-dev target is probably subclass of full install). I need tchar.h... Thanks, Juraj

2 1

Netapi32 ??
by Martin Wilck 17 Sep '02

17 Sep '02

The app I am trying to port with winelib makes heavy use of calls to the netapi32 DLL to check for permissions, etc. I just took a glance over the spec file and found it consists mainly of stubs. Is anybody (Mike?) currently working on netapi32, are there plans to implement larger parts, what are the main problems? I guess this points towards the general Wine/Samba integration that Mike has been talking about earlier... Grateful for any hints, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

3 7

Re: WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

I noticed in regedit's Makefile.in that it lists msvcrt, advapi32, and kernel32 in it's IMPORTS variable and has no foo_DLLS variable, whereas Winemaker by default puts most of those in the foo_DLLS variable. What's the difference between the DLLS variable and the IMPORTS variable? -Steve Andriy Palamarchuk To: Steve Lustbader/ANR/MS/PHILIPS@AMEC <apa3a(a)yahoo.com wine-devel(a)winehq.com > cc: Subject: Re: WineLib with MSVCRT 09/16/2002 03:02 PM Classification: --- steve.lustbader(a)philips.com wrote: > What is the proper way to use the MSVCRT in WineLib? Check out how Wine programs (e.g. regedit) use MSVCRT. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

SFU port part2
by Steven Edwards 17 Sep '02

17 Sep '02

ok got configure working but some of the porting definitions are hosed. When I try to build anything I get this: ../include/wine/port.h:49: Error: conflicting types for `mode_t' /usr/include/sys/types.h:45: Error: previous declaration of `mode_t' ../include/wine/port.h:52: Warning: redefinition of `off_t' /usr/include/sys/types.h:69: Warning: `off_t' previously declared here ../include/wine/port.h:55: Error: conflicting types for `pid_t' /usr/include/sys/types.h:55: Error: previous declaration of `pid_t' ../include/wine/port.h:58: Warning: redefinition of `size_t' /usr/include/sys/types.h:89: Warning: `size_t' previously declared here ../include/wine/port.h:61: Warning: redefinition of `ssize_t' /usr/include/sys/types.h:94: Warning: `ssize_t' previously declared here Any suggestions? Thanks Steven

2 2

Re: DefineDosDevice - ??
by Martin Wilck 17 Sep '02

17 Sep '02

Am Die, 2002-09-17 um 20.48 schrieb Mike McCormack: > Did you get my other mails? I'll include the text again... they don't > seem to have made it to wine-devel, so I'm wondering if they got > anywhere at all... No they didn't, at least not to me. Thanks for resending... > BTW. The PAM module you are talking about was a goal of Samba TNG. "Was" - does that mean the project is dead? I reckon that the "winbind" module of the current Samba release is pretty close to what we want in terms of host, user, and group lookup. > I think that can be done with a NetBIOS QUERY packet with "*" as the > name to query. You'll then get every machine on your local network > sending a QUERY RESPONSE packet back to you with the machine's name. > > The operation is similar to the code to resolve a NetBIOS name (see > NB_Lookup in files/smb.c) I need yet to understand how all these things relate. Winsock may use NetBIOS as a service provider, but NetBIOS seems to offer an independent interface to other APIs as well, right? If I understand you right, the Netbios stuff is then located somewhere in kernel32. Is the winsock provider an independent package or part of the NetBIOS core? > The named pipes code needs to be rewritten to work through SMB so that > we can support DCOM clients (computer to computer). Supporting a DCOM > server is a problem because Samba is usually in the way on the ports we > need to listen to... it would be nice to have some way for Samba and > Wine to work together... a Netbios kernel module perhaps? IMO this raises more fundamental questions about the role wine should play. Samba is a service offered by the Unix system on which wine is running. If wine were to grab the NetBIOS ports, it would take over this service functionality; I doubt that's a good approach. Wine could perhaps offer services on an IP alias instead, somewhat similar as described in http://www.deschner.de/gd/dual_samba.html > shell32 manages passwords and shares through MPR.DLL. We need to add > some code to show the Network Neighbourhood icon and probe any connected > shares, connect new shares, etc to shell32. > > If you need something specific, I'll see what I can do, but a full > implementation is probably a bit much for this weekend ;-) I think it needs to be clarified what we're actually heading for. As I said, I consider it potentially dangerous if wine offers services on the network bypassing the ordinary Unix security mechanism. Acting as a client is a different story, I guess we want maximum functionality in that area. When it comes to User authentication, I am strongly for wine communicating with the Unix system (e.g. PAM). Then if PAM supports NT domain authentication (through samba or whatever), Active directory AKA LDAP authentication, etc., wine would, too. We'd just have to ensure that we don't loose too much on our way through the Unix layer. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

WineLib with MSVCRT
by steve.lustbader＠philips.com 17 Sep '02

17 Sep '02

What is the proper way to use the MSVCRT in WineLib? I tried adding a -I/usr/local/include/wine/msvcrt to the list of includes and -nostdinc to CXXEXTRA, but then gcc can't find stdarg.h, which is included in windows.h via winbase.h. If I use -nostdinc++, gcc is able to find stdarg.h, but it runs into problems with other files, such iostream.h. Finally, if I don't use either -nostdinc or -nostdinc++, gcc complains about types being redefined, such as wint_t (as an unsigned short int in /usr/include/_G_config.h but WCHAR in /usr/local/include/wine/msvcrt/wctype.h). It seems like using -nostdinc would be the right way, but does that mean that Wine needs to include its own copy of stdarg.h and related files? -Steve

3 2

PATCH: workaround for ms typo
by Michael Stefaniuc 17 Sep '02

17 Sep '02

Hello, this email is CC'ed to wine-devel because it's controversial. MS made a typo in CHOOSECOLOR (commdlg.h) and kept it till today (at least that's what msdn says): the struct member hInstance is a HWND instead of a HINSTANCE. Until now it wasn't a problem in wine but with the conversions of the handles to void* a lot of casts are necessary. And this casts are looking just wrong: cast to HINSTANCE when using the hInstance member as rvalue and cast to HWND when using it as lvalue. The casts looks so wrong so that we would need comments like "Yes, this cast is needed, see struct CHOOSECOLOR in include/commdlg.h". The attached patch fixes the typo for wine (but keeps it for compatibility reasons for winelib) and removes the need of some ugly casts. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - workaround for MS typo bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Direct3D v8
by Ann and Jason Edmeades 16 Sep '02

16 Sep '02

Hello, What is the current state of affairs regarding DirectX (8) support in wine. With Transgaming producing a version which appears to work well from what I read on the Internet, what is happening about getting support for it in the wine tree - Is the intention to wait and see what Transgaming do? The reason I ask - Not to start a political debate with pros and cons of Transgaming, but more because as a learning exercise with regard to 3d graphics, I started fiddling with Direct X 8 support and have some sample code which runs some simple Direct3D samples and most of a sequence of tutorials. (9 out of 11 work reasonably well). I dont have a problem with the code remaining personal to me and probably archived, as I have learnt a lot by doing it (which was my original aim), but if it is agreed that adding directx 8 support completely different to the Transgaming code is ok, then I may try to submit some patches. Note the current code is nowhere near ideal, so dont get your hopes up. Specifically, it exports X11DRV_get_client_window from X11DRV as a means of getting the X window from the HWND, which is not clean. It does not use a HAL (which is where the current ddraw code was starting to head), it calls all the opengl calls inline. I have only tested on one machine with one level of mesa (tough! thats all I have). It also has all the c parts in the d3d8 directory, completely seperate (and in some cases duplicating code from the ddraw code), which may or may not be desired. I also dont have a clue about the configure tests and makefile.in, so I have just a basic structure which works enough for me. I'm also relatively certain I havent necessarily used the highest performing code everywhere, I have done the best I could with my limited knowledge. The way I look at it would be a starting point for others to work from. I could make a drop of the code on a website if anyone wants to see how bad it is first :-) Anyway, thoughts please? Jason

8 17

Re: memory/virtual.c: ROUND_SIZE() bugfix + .SYS loading
by Alexandre Julliard 16 Sep '02

16 Sep '02

Jan Kratochvil <short(a)ucw.cz> writes: > I had incorrect warnings "Section %.8s too large (%lx+%lx/%lx)" during loading > of some low-level system libraries. It got fixed by the attached > "wine-memory-virtual.c-too_large_section.diff" which changes (I think fixes) > ROUND_SIZE() behaviour. It also comments ROUND_ADDR() and ROUND_SIZE(), I hope > I guessed its intended description from the style of its usage around the code. No, ROUND_SIZE is supposed to return an aligned size, which you use together with an aligned address. The normal pattern is to use ROUND_SIZE and ROUND_ADDR together. We don't bother to round addresses in image mapping because all the code assumes the image has correct section alignment already. > Attached "wine-memory-virtual.c-mmap_cache-preliminary.diff" is just a RFC as > I found out that I was unable to load some .SYS files as they were being > attempted to be loaded with page-overlapping sections, unaligned offsets and > incompatible protections. Therefore I had to implement my own mapping cache and > handle the overlapping/merging myself. It would be more simple/clean to use > Linux /proc/$$/maps mmap map but it would be probably no-no as it is > Linux-dependent. I think this is complete overkill. Mapping unaligned binaries is a very unusual case and should be treated as such. There's no need to maintain such a complex structure, or add support for non page aligned mmaps, for such an exotic feature. Probably what you want is to create a separate map_image_unaligned function to map images that don't have a proper section alignment, using read() and not worrying about protections at all. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Replace static initializers with a proper #define in .h files
by Alexandre Julliard 16 Sep '02

16 Sep '02

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, your patch committed at 02/08/14 16:09:55 (Builtin modules > must be aligned on 64K boundary) completely kills any attempts to > minimize sizes of winelib executables. Is it really necessary? Yes, some apps need modules to be properly aligned. Note that this stuff will never be paged in so it only wastes a bit of disk space. -- Alexandre Julliard julliard(a)winehq.com

1 0

Question about "undefined" functions
by Sylvain Petreolle 16 Sep '02

16 Sep '02

Hi, I have problems with the following functions: 17 0x4073bf2f (USER32.DLL.GetTaskmanWindow+0xdf in user32.dll.so) (ebp=405c24d0) 18 0x4073bfa3 (USER32.DLL.GetTaskmanWindow+0x153 in user32.dll.so) (ebp=405c2508) 19 0x40742936 (USER32.DLL.CallWindowProcA+0x136 in user32.dll.so) (ebp=405c253c) 20 0x4071c21b (USER32.DLL.DispatchMessageA+0xbb in user32.dll.so) (ebp=405c2570 In some programs this call stack appears when going to debugger and is causing 0x0 read acess.Digging in the source shows that these functions are only defined by a stdcall in the spec file of user32. the result is a return '0x0000' in the user32.spec.c: "\tjmp GetTaskmanWindow\n" "\tret $0x0000\n" Are these functions intended to return 0x0 ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: winedump: selective search also by name
by Eric Pouech 16 Sep '02

16 Sep '02

> > I am missing some general utility library such as GLib, Qt, NSPR or APR to > > provide general datastructures such as hashes etc. Maybe it is provided by W32? > > Therefore /* FIXME: Replace with some hash such as GHashTable */. it'll be a bad idea to use extra libs like Qt or Glib in Wine, just for that (note also, that in your case, a simple binary search would be enough IMO (compared to the current linear search) A+

2 1

Re: Shell icons - legal
by Jeff Smith 16 Sep '02

16 Sep '02

1 0

DefineDosDevice - ??
by Martin Wilck 16 Sep '02

16 Sep '02

This function is currently a stub - are there any major problems supporting it, i.e. supporting dynamic creation and deletion of DOS drives? Does Wine have a notion of Device paths that look like "\\Device\\Harddisk2\\Partition1" at all? Thinking about it, does something like this make sense at all in the Wine context? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

winebuild/main.c: Include ctype
by Uwe Bonnes 16 Sep '02

16 Sep '02

Changelog: tools/winebuild/main.c Include ctype.h as isdigit is used -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/tools/winebuild/main.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/main.c,v retrieving revision 1.37 diff -u -w -r1.37 main.c --- wine/tools/winebuild/main.c 12 Sep 2002 22:51:20 -0000 1.37 +++ wine/tools/winebuild/main.c 16 Sep 2002 16:00:04 -0000 @@ -26,6 +26,7 @@ #include "wine/port.h" #include <assert.h> +#include <ctype.h> #include <stdio.h> #include <errno.h> #include <string.h>

1 0

Re: Fixed selecting multiple files in common file dialog 95-style
by Huw Davies 16 Sep '02

16 Sep '02

On Sun, Sep 15, 2002 at 08:31:27PM +0200, Josef Meixner wrote: > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.80 > diff -r1.80 filedlg95.c [snip] > 1457c1464,1466 > < memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); > --- > > memset( ofn->lpstrFile + nSizePath, 0, sizeof(WCHAR) ); > > memcpy( ofn->lpstrFile + nSizePath + sizeof(WCHAR), lpstrFileList, > > sizeUsed*sizeof(WCHAR) ); > 1463,1466c1472,1483 > < WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > < ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > < WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > < &ofn->lpstrFile[nSizePath], ofn->nMaxFile - nSizePath, NULL, NULL); > --- > > if (ofn->lpstrFile != NULL) > > { > > WideCharToMultiByte(CP_ACP, 0, lpstrPathSpec, -1, > > ofn->lpstrFile, ofn->nMaxFile, NULL, NULL); > > if (ofn->nMaxFile > nSizePath + 1) > > { > > ofn->lpstrFile[nSizePath] = '\0'; > > WideCharToMultiByte(CP_ACP, 0, lpstrFileList, sizeUsed, > > ofn->lpstrFile + nSizePath + 1, > > ofn->nMaxFile - nSizePath, NULL, NULL); > > } > > } > The last two hunks of this patch aren't right. Alexandre, please use this one instead. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

PATCH: Fix MoveFileEx() flags in MSVCRT rename()
by Martin Wilck 16 Sep '02

16 Sep '02

[ Forwarding to wine-devel because it may be controversial, please see comments below. ] Patch: rename.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-16 Modified files: - wine/dlls/msvcrt: file.c Log Message: * Fix MoveFileEx() flags in MSVCRT rename()/_wrename() Comment: >From MSDN docs for rename()/_wrename(): "The new name must not be the name of an existing file or directory. You can use rename to move a file from one directory or device to another by giving a different path in the newname argument." This clearly says that MOVEFILE_REPLACE_EXISTING should _not_ be set, while MOVEFILE_COPY_ALLOWED is necessary to allow moving files between drives. I have verified that windows actually behaves as stated in the MSDN excerpt above. Perhaps someone knows why the flags have been set this way - is it a workaround for some hidden feature in some Windows version? Index: dlls/msvcrt/file.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/file.c,v retrieving revision 1.37 diff -u -r1.37 file.c --- dlls/msvcrt/file.c 12 Sep 2002 22:28:01 -0000 1.37 +++ dlls/msvcrt/file.c 16 Sep 2002 09:16:07 -0000 @@ -2107,7 +2107,7 @@ int MSVCRT_rename(const char *oldpath,const char *newpath) { TRACE(":from %s to %s\n",oldpath,newpath); - if (MoveFileExA(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExA(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); @@ -2120,7 +2120,7 @@ int _wrename(const WCHAR *oldpath,const WCHAR *newpath) { TRACE(":from %s to %s\n",debugstr_w(oldpath),debugstr_w(newpath)); - if (MoveFileExW(oldpath, newpath, MOVEFILE_REPLACE_EXISTING)) + if (MoveFileExW(oldpath, newpath, MOVEFILE_COPY_ALLOWED)) return 0; TRACE(":failed (%ld)\n",GetLastError()); MSVCRT__set_errno(GetLastError()); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: Replace static initializers with a proper #define in .h files
by Francois Gouget 16 Sep '02

16 Sep '02

On Sat, 14 Sep 2002, Dmitry Timoshkov wrote: > Hello. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Replace static initializers with a proper #define in .h files. Are defines really better? It seemed to me that they had at least one disadvantage: the value is duplicated each time the define is used. Hmmm, I just retested and it looks as if I was wrong. Anyway, what are the pros and cons? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

3 5

Strange behaviour in directory/drive traversal
by Sylvain Petreolle 16 Sep '02

16 Sep '02

I installed a program and want to launch it. Configuration : ls -ld /c lrwxrwxrwx 1 root root 7 déc 21 2001 /c -> /home/c ls -ld /c/Program\ Files/Yahoo\!/Messenger/YPager.exe -rwxr-xr-x 1 syl wine 1044480 mai 28 17:52 /c/Program Files/Yahoo\!/Messenger/YPager.exe C drive is set to : [Drive C] "Path" = "/home/c" "Type" = "hd" "Filesystem" = "win95" I got: [syl@snoop syl]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I go to drive C: [syl@snoop syl]$ cd /c [syl@snoop c]$ wine /c/Program\ Files/Yahoo\!/Messenger/YPager.exe Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive Warning: L"/c/Program Files/Yahoo!/Messenger/YPager.exe" not accessible from a configured DOS drive wine: cannot find '/c/Program Files/Yahoo!/Messenger/YPager.exe' I finally go to the program directory: [syl@snoop c]$ cd /c/Program\ Files/Yahoo\!/Messenger/ [syl@snoop Messenger]$ wine YPager.exe and it launches ... Comments ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Wine Hides On-board RAM
by Ian D. Stewart 16 Sep '02

16 Sep '02

On 2002.08.18 12:21 Andreas Mohr wrote: > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > I have recently noticed an unusual side-effect of running Wine. > When I > > first start up my system, /proc/meminfo reports MemTotal as 256892 > kb. > > After running Wine for awhile, /proc/meminfo reports MemTotal as > 32680 > > kb. The system performs as if it only had 32 MB of RAM. A reboot > of > > the system resets total memory to the proper value. > > > > My question is: > > > > 1) Has anybody else encountered this? > > 2) Does anyone know what causes this, or better yet how to avoid it? > > 3) Is there anyway to recover the lost RAM short of a reboot? > > Huh ? This is very, very, VERY strange ! > Something like this should never happen. > Are you sure it's caused by Wine only, or maybe it is due to faulty > memory > instead ? (and thus the board/Linux notices that only 32MB are useable > and resorts to accessing 32MB only). Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine. I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot. > > Again, I'm utterly puzzled when hearing such a story. > Or maybe Wine accesses some Linux memory management function in some > way > that causes Linux to tamper with the value for some reason ? > This wouldn't be the first time that Wine is the only program to > reveal > some severe bug in Linux memory management... > > Definitely try upgrading your kernel, too. I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens. Thanx for the input, Andreas. Ian

5 8

ntdll.dll vs. ntoskrnl.exe
by Jan Kratochvil 15 Sep '02

15 Sep '02

Hi, What are the differences between "ntdll.dll" and "ntoskrnl.exe"? In Windows XP they exist both and they export similiar (although different) set of functions. Wine implements just "ntdll.dll". Some W32 binary wants to import functions from "ntoskrnl.exe" from me, should I make an alias of Wine "ntdll.dll" to "ntoskrnl.exe" and try to fill the missing funcs? I have never seen W32 programming before as I am *IX coder. Thanks, Jan Kratochvil

5 8

Re: Direct3D v8
by Sylvain Petreolle 15 Sep '02

15 Sep '02

did someone try to compile it with winemaker ? it seems to have only m$ project files... --- "P. Christeas" <p_christ(a)hol.gr> a écrit : > I just saw a sourceforge project about that. See: > http://sourceforge.net/projects/dxglwrap/ > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Building WINE under Microsoft Services for UNIX
by Steven Edwards 15 Sep '02

15 Sep '02

Hola, I wanted to start working on a port to SFU now that we are making progress on the Cygwin and Mingw port and am having a little trouble. SFU doesnt come with binutils and has a older gcc (2.7). I have upgraded the gcc to the 3.x release and am having trouble getting WINE to build. SFU has support for building .SO and .dll files although I dont really know how it differs from Linux is this regard. Attached is my config.log Thanks Steven This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 20020904, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = ph33r uname -m = x86 uname -r = 3.0 uname -s = Interix uname -v = SP-7.0.1701.1 /usr/bin/uname -p = AMD Duron /bin/uname -X = System = Interix Node = ph33r Release = 3.0 Version = SP-7.0.1701.1 Machine = x86 Processor = AMD Duron HostSystem = Windows HostRelease = SP3 HostVersion = 5.0 /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /bin PATH: /usr/contrib/bin PATH: /usr/X11R5/bin PATH: /usr/local/bin PATH: /usr/contrib/win32/bin PATH: /dev/fs/C/WINNT/system32 PATH: /dev/fs/C/SFU/common ## ----------- ## ## Core tests. ## ## ----------- ## configure:1300: checking build system type configure:1318: result: i386-pc-interix3 configure:1326: checking host system type configure:1340: result: i386-pc-interix3 configure:1348: checking whether make sets ${MAKE} configure:1368: result: yes configure:1423: checking for gcc configure:1439: found /usr/contrib/bin/gcc configure:1449: result: gcc configure:1693: checking for C compiler version configure:1696: gcc --version </dev/null >&5 cygnus-2.7.2-970404 configure:1699: $? = 0 configure:1701: gcc -v </dev/null >&5 Using builtin specs. gcc version cygnus-2.7.2-970404 configure:1704: $? = 0 configure:1706: gcc -V </dev/null >&5 gcc: argument to `-V' is missing configure:1709: $? = 1 configure:1735: checking for C compiler default output configure:1738: gcc conftest.c >&5 configure:1741: $? = 0 configure:1774: result: a.out configure:1779: checking whether the C compiler works configure:1785: ./a.out configure:1788: $? = 0 configure:1803: result: yes configure:1810: checking whether we are cross compiling configure:1812: result: no configure:1815: checking for suffix of executables configure:1817: gcc -o conftest conftest.c >&5 configure:1820: $? = 0 configure:1842: result: configure:1848: checking for suffix of object files configure:1872: gcc -c conftest.c >&5 configure:1875: $? = 0 configure:1894: result: o configure:1898: checking whether we are using the GNU C compiler configure:1925: gcc -c conftest.c >&5 configure:1928: $? = 0 configure:1931: test -s conftest.o configure:1934: $? = 0 configure:1946: result: yes configure:1952: checking whether gcc accepts -g configure:1976: gcc -c -g conftest.c >&5 configure:1979: $? = 0 configure:1982: test -s conftest.o configure:1985: $? = 0 configure:1995: result: yes configure:2022: gcc -c -g -O2 conftest.c >&5 conftest.c:2: syntax error before `me' configure:2025: $? = 1 configure: failed program was: #ifndef __cplusplus choke me #endif configure:2140: checking how to run the C preprocessor configure:2166: gcc -E conftest.c configure:2172: $? = 0 configure:2199: gcc -E conftest.c configure:2195: ac_nonexistent.h: No such file or directory configure:2205: $? = 1 configure: failed program was: #line 2194 "configure" #include "confdefs.h" #include <ac_nonexistent.h> configure:2242: result: gcc -E configure:2257: gcc -E conftest.c configure:2263: $? = 0 configure:2290: gcc -E conftest.c configure:2286: ac_nonexistent.h: No such file or directory configure:2296: $? = 1 configure: failed program was: #line 2285 "configure" #include "confdefs.h" #include <ac_nonexistent.h> configure:2336: checking for the directory containing the Wine tools configure:2360: result: $(TOPOBJDIR) configure:2367: checking for X configure:2583: result: libraries /usr/X11R5/lib, headers /usr/X11R5/include configure:2740: gcc -o conftest -g -O2 conftest.c -L/usr/X11R5/lib -lX11 >&5 configure:2743: $? = 0 configure:2746: test -s conftest configure:2749: $? = 0 configure:2887: checking for gethostbyname configure:2930: gcc -o conftest -g -O2 conftest.c >&5 configure:2933: $? = 0 configure:2936: test -s conftest configure:2939: $? = 0 configure:2949: result: yes configure:3082: checking for connect configure:3125: gcc -o conftest -g -O2 conftest.c >&5 configure:3128: $? = 0 configure:3131: test -s conftest configure:3134: $? = 0 configure:3144: result: yes configure:3210: checking for remove configure:3253: gcc -o conftest -g -O2 conftest.c >&5 configure:3256: $? = 0 configure:3259: test -s conftest configure:3262: $? = 0 configure:3272: result: yes configure:3338: checking for shmat configure:3381: gcc -o conftest -g -O2 conftest.c >&5 configure:3384: $? = 0 configure:3387: test -s conftest configure:3390: $? = 0 configure:3400: result: yes configure:3475: checking for IceConnectionNumber in -lICE configure:3508: gcc -o conftest -g -O2 -L/usr/X11R5/lib conftest.c -lICE >&5 ld: cannot open -lICE: No such file or directory configure:3511: $? = 1 configure: failed program was: #line 3482 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char IceConnectionNumber (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { IceConnectionNumber (); ; return 0; } configure:3528: result: no configure:3542: checking for bison configure:3571: result: no configure:3542: checking for byacc configure:3571: result: no configure:3583: checking for flex configure:3612: result: no configure:3583: checking for lex configure:3599: found /bin/lex configure:3609: result: lex configure:3622: checking for yywrap in -lfl configure:3655: gcc -o conftest -g -O2 conftest.c -lfl >&5 ld: cannot open -lfl: No such file or directory configure:3658: $? = 1 configure: failed program was: #line 3629 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char yywrap (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { yywrap (); ; return 0; } configure:3675: result: no configure:3680: checking for yywrap in -ll configure:3713: gcc -o conftest -g -O2 conftest.c -ll >&5 configure:3716: $? = 0 configure:3719: test -s conftest configure:3722: $? = 0 configure:3733: result: yes configure:3744: checking lex output file root configure:3755: lex conftest.l configure:3758: $? = 0 configure:3770: result: lex.yy configure:3775: checking whether yytext is a pointer configure:3791: gcc -o conftest -g -O2 conftest.c -ll >&5 configure:3794: $? = 0 configure:3797: test -s conftest configure:3800: $? = 0 configure:3812: result: yes configure:3828: checking for yacc configure:3844: found /bin/yacc configure:3854: result: yacc configure:3875: checking for lex configure:3891: found /bin/lex configure:3901: result: lex configure:3960: checking for ld configure:3976: found /usr/contrib/bin/ld configure:3987: result: ld configure:4040: checking for ar configure:4056: found /bin/ar configure:4067: result: ar configure:4120: checking for ranlib configure:4136: found /bin/ranlib configure:4147: result: ranlib configure:4200: checking for strip configure:4216: found /bin/strip configure:4227: result: strip configure:4280: checking for windres configure:4307: result: false configure:4331: checking for a BSD-compatible install configure:4385: result: /bin/install -c configure:4396: checking whether ln -s works configure:4400: result: yes configure:4407: checking whether ln works configure:4419: result: no, using cp -p configure:4425: checking for c2man configure:4452: result: $(TOPSRCDIR)/tools/c2man.pl configure:4461: checking for ldconfig configure:4492: result: true configure:4504: checking for lclint configure:4533: result: no configure:4504: checking for lint configure:4533: result: no configure:4549: checking for sqrt in -lm configure:4582: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:4564: warning: conflicting types for built-in function `sqrt' configure:4585: $? = 0 configure:4588: test -s conftest configure:4591: $? = 0 configure:4602: result: yes configure:4614: checking for i386_set_ldt in -li386 configure:4647: gcc -o conftest -g -O2 conftest.c -li386 -lm >&5 ld: cannot open -li386: No such file or directory configure:4650: $? = 1 configure: failed program was: #line 4621 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char i386_set_ldt (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { i386_set_ldt (); ; return 0; } configure:4667: result: no configure:4679: checking for _oss_ioctl in -lossaudio configure:4712: gcc -o conftest -g -O2 conftest.c -lossaudio -lm >&5 ld: cannot open -lossaudio: No such file or directory configure:4715: $? = 1 configure: failed program was: #line 4686 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char _oss_ioctl (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { _oss_ioctl (); ; return 0; } configure:4732: result: no configure:4747: checking for iswalnum configure:4790: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccky4zOe.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:4780: undefined reference to `iswalnum' configure:4793: $? = 1 configure: failed program was: #line 4752 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char iswalnum (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char iswalnum (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_iswalnum) || defined (__stub___iswalnum) choke me #else f = iswalnum; #endif ; return 0; } configure:4809: result: no configure:4818: checking for iswalnum in -lw configure:4851: gcc -o conftest -g -O2 conftest.c -lw -lm >&5 ld: cannot open -lw: No such file or directory configure:4854: $? = 1 configure: failed program was: #line 4825 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char iswalnum (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { iswalnum (); ; return 0; } configure:4871: result: no configure:4889: checking for gethostbyname configure:4951: result: yes configure:5031: checking for connect configure:5093: result: yes configure:5173: checking for inet_aton configure:5216: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:5219: $? = 0 configure:5222: test -s conftest configure:5225: $? = 0 configure:5235: result: yes configure:5312: checking for _xpg4_setrunelocale in -lxpg4 configure:5345: gcc -o conftest -g -O2 conftest.c -lxpg4 -lm >&5 ld: cannot open -lxpg4: No such file or directory configure:5348: $? = 1 configure: failed program was: #line 5319 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char _xpg4_setrunelocale (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { _xpg4_setrunelocale (); ; return 0; } configure:5365: result: no configure:5377: checking for mmap in -lmmap configure:5410: gcc -o conftest -g -O2 conftest.c -lmmap -lm >&5 ld: cannot open -lmmap: No such file or directory configure:5413: $? = 1 configure: failed program was: #line 5384 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char mmap (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { mmap (); ; return 0; } configure:5430: result: no configure:5444: checking for ANSI C header files configure:5458: gcc -E conftest.c configure:5464: $? = 0 configure:5551: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:5554: $? = 0 configure:5556: ./conftest configure:5559: $? = 0 configure:5573: result: yes configure:5597: checking for sys/types.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for sys/stat.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for stdlib.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for string.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for memory.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for strings.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5597: checking for inttypes.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5638: inttypes.h: No such file or directory configure:5613: $? = 1 configure: failed program was: #line 5602 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <inttypes.h> configure:5629: result: no configure:5597: checking for stdint.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5638: stdint.h: No such file or directory configure:5613: $? = 1 configure: failed program was: #line 5602 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <stdint.h> configure:5629: result: no configure:5597: checking for unistd.h configure:5610: gcc -c -g -O2 conftest.c >&5 configure:5613: $? = 0 configure:5616: test -s conftest.o configure:5619: $? = 0 configure:5629: result: yes configure:5655: checking jpeglib.h usability configure:5664: gcc -c -g -O2 conftest.c >&5 configure:5692: jpeglib.h: No such file or directory configure:5667: $? = 1 configure: failed program was: #line 5657 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <jpeglib.h> configure:5682: result: no configure:5686: checking jpeglib.h presence configure:5693: gcc -E conftest.c configure:5689: jpeglib.h: No such file or directory configure:5699: $? = 1 configure: failed program was: #line 5688 "configure" #include "confdefs.h" #include <jpeglib.h> configure:5717: result: no configure:5735: checking for jpeglib.h configure:5742: result: no configure:5849: checking X11/Xlib.h usability configure:5858: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:5861: $? = 0 configure:5864: test -s conftest.o configure:5867: $? = 0 configure:5876: result: yes configure:5880: checking X11/Xlib.h presence configure:5887: gcc -E -I/usr/X11R5/include conftest.c configure:5893: $? = 0 configure:5911: result: yes configure:5929: checking for X11/Xlib.h configure:5936: result: yes configure:5949: checking for X11/XKBlib.h configure:5962: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:5957: X11/XKBlib.h: No such file or directory configure:5965: $? = 1 configure: failed program was: #line 5954 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/XKBlib.h> configure:5981: result: no configure:6052: WARNING: Xkb extension not found, Wine will be built without it configure:6063: checking for X11/extensions/XShm.h configure:6076: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6079: $? = 0 configure:6082: test -s conftest.o configure:6085: $? = 0 configure:6095: result: yes configure:6101: checking for XShmQueryExtension in -lXext configure:6134: gcc -o conftest -g -O2 -I/usr/X11R5/include conftest.c -lXext -L/usr/X11R5/lib -lXext -lX11 -lm >&5 /tmp/ccFkOVtc.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:6126: undefined reference to `XShmQueryExtension' configure:6137: $? = 1 configure: failed program was: #line 6108 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char XShmQueryExtension (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { XShmQueryExtension (); ; return 0; } configure:6154: result: no configure:6177: checking for X11/Xutil.h configure:6190: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6193: $? = 0 configure:6196: test -s conftest.o configure:6199: $? = 0 configure:6209: result: yes configure:6225: checking for X11/extensions/shape.h configure:6241: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6244: $? = 0 configure:6247: test -s conftest.o configure:6250: $? = 0 configure:6260: result: yes configure:6266: checking for XShapeQueryExtension in -lXext configure:6299: gcc -o conftest -g -O2 -I/usr/X11R5/include conftest.c -lXext -L/usr/X11R5/lib -lXext -lX11 -lm >&5 configure:6302: $? = 0 configure:6305: test -s conftest configure:6308: $? = 0 configure:6319: result: yes configure:6342: checking for X11/extensions/xf86dga.h configure:6355: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6350: X11/extensions/xf86dga.h: No such file or directory configure:6358: $? = 1 configure: failed program was: #line 6347 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/xf86dga.h> configure:6374: result: no configure:6516: WARNING: DGA extension not found, Wine will be built without it configure:6527: checking for X11/extensions/xf86vmode.h configure:6540: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6535: X11/extensions/xf86vmode.h: No such file or directory configure:6543: $? = 1 configure: failed program was: #line 6532 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/xf86vmode.h> configure:6559: result: no configure:6633: WARNING: XFree86 VMODE extension not found, Wine will be built without it configure:6644: checking for X11/extensions/Xvlib.h configure:6657: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6652: X11/extensions/Xvlib.h: No such file or directory configure:6660: $? = 1 configure: failed program was: #line 6649 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/Xvlib.h> configure:6676: result: no configure:6750: WARNING: XVideo extension not found, Wine will be built without it configure:6761: checking for X11/extensions/Xrender.h configure:6774: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6769: X11/extensions/Xrender.h: No such file or directory configure:6777: $? = 1 configure: failed program was: #line 6766 "configure" #include "confdefs.h" #include <X11/Xlib.h> #include <X11/extensions/Xrender.h> configure:6793: result: no configure:6836: checking GL/gl.h usability configure:6845: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6873: GL/gl.h: No such file or directory configure:6848: $? = 1 configure: failed program was: #line 6838 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <GL/gl.h> configure:6863: result: no configure:6867: checking GL/gl.h presence configure:6874: gcc -E -I/usr/X11R5/include conftest.c configure:6870: GL/gl.h: No such file or directory configure:6880: $? = 1 configure: failed program was: #line 6869 "configure" #include "confdefs.h" #include <GL/gl.h> configure:6898: result: no configure:6916: checking for GL/gl.h configure:6923: result: no configure:6836: checking GL/glx.h usability configure:6845: gcc -c -g -O2 -I/usr/X11R5/include conftest.c >&5 configure:6873: GL/glx.h: No such file or directory configure:6848: $? = 1 configure: failed program was: #line 6838 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <GL/glx.h> configure:6863: result: no configure:6867: checking GL/glx.h presence configure:6874: gcc -E -I/usr/X11R5/include conftest.c configure:6870: GL/glx.h: No such file or directory configure:6880: $? = 1 configure: failed program was: #line 6869 "configure" #include "confdefs.h" #include <GL/glx.h> configure:6898: result: no configure:6916: checking for GL/glx.h configure:6923: result: no configure:7374: checking ncurses.h usability configure:7383: gcc -c -g -O2 conftest.c >&5 configure:7411: ncurses.h: No such file or directory configure:7386: $? = 1 configure: failed program was: #line 7376 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <ncurses.h> configure:7401: result: no configure:7405: checking ncurses.h presence configure:7412: gcc -E conftest.c configure:7408: ncurses.h: No such file or directory configure:7418: $? = 1 configure: failed program was: #line 7407 "configure" #include "confdefs.h" #include <ncurses.h> configure:7436: result: no configure:7454: checking for ncurses.h configure:7461: result: no configure:7722: checking for getbkgd configure:7765: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccRhSFca.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:7755: undefined reference to `getbkgd' configure:7768: $? = 1 configure: failed program was: #line 7727 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getbkgd (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getbkgd (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getbkgd) || defined (__stub___getbkgd) choke me #else f = getbkgd; #endif ; return 0; } configure:7784: result: no configure:7722: checking for resizeterm configure:7765: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/ccPUiDhe.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:7755: undefined reference to `resizeterm' configure:7768: $? = 1 configure: failed program was: #line 7727 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char resizeterm (); below. */ #include <assert.h> /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char resizeterm (); char (*f) (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_resizeterm) || defined (__stub___resizeterm) choke me #else f = resizeterm; #endif ; return 0; } configure:7784: result: no configure:7800: checking for cupsGetPPD in -lcups configure:7833: gcc -o conftest -g -O2 conftest.c -lcups -lm >&5 ld: cannot open -lcups: No such file or directory configure:7836: $? = 1 configure: failed program was: #line 7807 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char cupsGetPPD (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { cupsGetPPD (); ; return 0; } configure:7853: result: no configure:7976: checking for sane-config configure:8003: result: no configure:8201: checking for FT_Init_FreeType in -lfreetype configure:8234: gcc -o conftest -g -O2 conftest.c -lfreetype -L/usr/X11R5/lib -lm >&5 ld: cannot open -lfreetype: No such file or directory configure:8237: $? = 1 configure: failed program was: #line 8208 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char FT_Init_FreeType (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { FT_Init_FreeType (); ; return 0; } configure:8254: result: no configure:8534: checking for parport header/ppdev.h configure:8558: gcc -c -g -O2 conftest.c >&5 configure:8540: linux/ppdev.h: No such file or directory configure:8561: $? = 1 configure: failed program was: #line 8539 "configure" #include "confdefs.h" #include <linux/ppdev.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ioctl (1,PPCLAIM,0) ; return 0; } configure:8578: result: no configure:8589: checking for va_copy configure:8615: gcc -o conftest -g -O2 conftest.c -lm >&5 /tmp/cciMfKJa.o: In function `main': /dev/fs/G/src/wine-dev/wine/configure:8606: undefined reference to `va_copy' configure:8618: $? = 1 configure: failed program was: #line 8594 "configure" #include "confdefs.h" #include <stdarg.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { va_list ap1, ap2; va_copy(ap1,ap2); ; return 0; } configure:8635: result: no configure:8645: checking for __va_copy configure:8671: gcc -o conftest -g -O2 conftest.c -lm >&5 configure:8674: $? = 0 configure:8677: test -s conftest configure:8680: $? = 0 configure:8691: result: yes configure:8702: checking for GNU style IPX support configure:8727: gcc -c -g -O2 conftest.c >&5 configure:8709: netipx/ipx.h: No such file or directory configure:8730: $? = 1 configure: failed program was: #line 8707 "configure" #include "confdefs.h" #include <sys/socket.h> #include <netipx/ipx.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ((struct sockaddr_ipx *)0)->sipx_family == AF_IPX ; return 0; } configure:8747: result: no configure:8760: checking for linux style IPX support configure:8786: gcc -c -g -O2 conftest.c >&5 configure:8767: asm/types.h: No such file or directory configure:8768: linux/ipx.h: No such file or directory configure:8789: $? = 1 configure: failed program was: #line 8765 "configure" #include "confdefs.h" #include <sys/socket.h> #include <asm/types.h> #include <linux/ipx.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ((struct sockaddr_ipx *)0)->sipx_family == AF_IPX ; return 0; } configure:8806: result: no configure:8834: checking sys/soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: sys/soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <sys/soundcard.h> configure:8861: result: no configure:8865: checking sys/soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: sys/soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <sys/soundcard.h> configure:8896: result: no configure:8914: checking for sys/soundcard.h configure:8921: result: no configure:8834: checking machine/soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: machine/soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <machine/soundcard.h> configure:8861: result: no configure:8865: checking machine/soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: machine/soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <machine/soundcard.h> configure:8896: result: no configure:8914: checking for machine/soundcard.h configure:8921: result: no configure:8834: checking soundcard.h usability configure:8843: gcc -c -g -O2 conftest.c >&5 configure:8871: soundcard.h: No such file or directory configure:8846: $? = 1 configure: failed program was: #line 8836 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <soundcard.h> configure:8861: result: no configure:8865: checking soundcard.h presence configure:8872: gcc -E conftest.c configure:8868: soundcard.h: No such file or directory configure:8878: $? = 1 configure: failed program was: #line 8867 "configure" #include "confdefs.h" #include <soundcard.h> configure:8896: result: no configure:8914: checking for soundcard.h configure:8921: result: no configure:8935: checking for Open Sound System configure:8973: gcc -c -g -O2 conftest.c >&5 configure:8963: #error No open sound system configure:8976: $? = 1 configure: failed program was: #line 8940 "configure" #include "confdefs.h" #if defined(HAVE_SYS_SOUNDCARD_H) #include <sys/soundcard.h> #elif defined(HAVE_MACHINE_SOUNDCARD_H) #include <machine/soundcard.h> #elif defined(HAVE_SOUNDCARD_H) #include <soundcard.h> #endif #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* check for one of the Open Sound System specific SNDCTL_ defines */ #if !defined(SNDCTL_DSP_STEREO) #error No open sound system #endif ; return 0; } configure:8992: result: no configure:9004: checking for Open Sound System/MIDI interface configure:9042: gcc -c -g -O2 conftest.c >&5 configure:9032: #error No open sound system MIDI interface configure:9045: $? = 1 configure: failed program was: #line 9009 "configure" #include "confdefs.h" #if defined(HAVE_SYS_SOUNDCARD_H) #include <sys/soundcard.h> #elif defined(HAVE_MACHINE_SOUNDCARD_H) #include <machine/soundcard.h> #elif defined(HAVE_SOUNDCARD_H) #include <soundcard.h> #endif #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { /* check for one of the Open Sound System specific SNDCTL_SEQ defines */ #if !defined(SNDCTL_SEQ_SYNC) #error No open sound system MIDI interface #endif ; return 0; } configure:9061: result: no configure:9075: checking for artsc-config configure:9108: result: no configure:9112: checking for aRts Sound server configure:9171: result: no configure:9205: checking alsa/asoundlib.h usability configure:9214: gcc -c -g -O2 conftest.c >&5 configure:9242: alsa/asoundlib.h: No such file or directory configure:9217: $? = 1 configure: failed program was: #line 9207 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <alsa/asoundlib.h> configure:9232: result: no configure:9236: checking alsa/asoundlib.h presence configure:9243: gcc -E conftest.c configure:9239: alsa/asoundlib.h: No such file or directory configure:9249: $? = 1 configure: failed program was: #line 9238 "configure" #include "confdefs.h" #include <alsa/asoundlib.h> configure:9267: result: no configure:9285: checking for alsa/asoundlib.h configure:9292: result: no configure:9205: checking sys/asoundlib.h usability configure:9214: gcc -c -g -O2 conftest.c >&5 configure:9242: sys/asoundlib.h: No such file or directory configure:9217: $? = 1 configure: failed program was: #line 9207 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <sys/asoundlib.h> configure:9232: result: no configure:9236: checking sys/asoundlib.h presence configure:9243: gcc -E conftest.c configure:9239: sys/asoundlib.h: No such file or directory configure:9249: $? = 1 configure: failed program was: #line 9238 "configure" #include "confdefs.h" #include <sys/asoundlib.h> configure:9267: result: no configure:9285: checking for sys/asoundlib.h configure:9292: result: no configure:9389: checking audio/audiolib.h usability configure:9398: gcc -c -g -O2 conftest.c >&5 configure:9426: audio/audiolib.h: No such file or directory configure:9401: $? = 1 configure: failed program was: #line 9391 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <audio/audiolib.h> configure:9416: result: no configure:9420: checking audio/audiolib.h presence configure:9427: gcc -E conftest.c configure:9423: audio/audiolib.h: No such file or directory configure:9433: $? = 1 configure: failed program was: #line 9422 "configure" #include "confdefs.h" #include <audio/audiolib.h> configure:9451: result: no configure:9469: checking for audio/audiolib.h configure:9476: result: no configure:9617: checking libaudioio.h usability configure:9626: gcc -c -g -O2 conftest.c >&5 configure:9654: libaudioio.h: No such file or directory configure:9629: $? = 1 configure: failed program was: #line 9619 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <libaudioio.h> configure:9644: result: no configure:9648: checking libaudioio.h presence configure:9655: gcc -E conftest.c configure:9651: libaudioio.h: No such file or directory configure:9661: $? = 1 configure: failed program was: #line 9650 "configure" #include "confdefs.h" #include <libaudioio.h> configure:9679: result: no configure:9697: checking for libaudioio.h configure:9704: result: no configure:9782: checking whether mmap64 works defined as mmap configure:9822: gcc -o conftest -g -O2 conftest.c -lm >&5 configure: In function `main': configure:9807: warning: comparison between pointer and integer configure:9825: $? = 0 configure:9827: ./conftest success! configure:9830: $? = 0 configure:9843: result: yes configure:9859: checking for gcc strength-reduce bug configure:9884: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure: In function `main': configure:9874: warning: comparison between signed and unsigned configure:9887: $? = 0 configure:9889: ./conftest configure:9892: $? = 0 configure:9905: result: no configure:9912: checking for gcc -mpreferred-stack-boundary=2 support configure:9938: gcc -o conftest -g -O2 -Wall -mpreferred-stack-boundary=2 conftest.c -lm >&5 cc1: Invalid option `preferred-stack-boundary=2' configure:9941: $? = 1 configure: failed program was: #line 9919 "configure" #include "confdefs.h" #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ; return 0; } configure:9958: result: no configure:9967: checking how to define a function in assembly code configure:9992: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:9995: $? = 0 configure:9998: test -s conftest configure:10001: $? = 0 configure:10085: result: .def configure:10114: checking whether external symbols need an underscore prefix configure:10139: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:10142: $? = 0 configure:10145: test -s conftest configure:10148: $? = 0 configure:10158: result: yes configure:10177: checking whether stdcall symbols need to be decorated configure:10202: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure:10205: $? = 0 configure:10208: test -s conftest configure:10211: $? = 0 configure:10221: result: yes configure:10233: checking whether assembler accepts .string configure:10258: gcc -o conftest -g -O2 -Wall conftest.c -lm >&5 configure: In function `ac_asm': configure:10239: syntax error before `test' configure:10261: $? = 1 configure: failed program was: #line 10238 "configure" #include "confdefs.h" void ac_asm(void) { asm(".data\n\t.string "test"\n\t.text"); } #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { ; return 0; } configure:10277: result: no configure:10343: checking for dllwrap configure:10370: result: false configure:10853: error: could not find a way to build shared libraries. It is currently not possible to build Wine without shared library (.so) support to allow transparent switch between .so and .dll files. If you are using Linux, you will need a newer binutils. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_asm_func_def=.def ac_cv_build=i386-pc-interix3 ac_cv_build_alias=i386-pc-interix3 ac_cv_c___va_copy=yes ac_cv_c_artsserver=no ac_cv_c_asm_string=no ac_cv_c_compiler_gnu=yes ac_cv_c_extern_prefix=yes ac_cv_c_gcc_stack_boundary=no ac_cv_c_gcc_strength_bug=no ac_cv_c_ipx_gnu=no ac_cv_c_ipx_linux=no ac_cv_c_opensoundsystem=no ac_cv_c_opensoundsystem_midi=no ac_cv_c_ppdev=no ac_cv_c_stdcall_decoration=yes ac_cv_c_va_copy=no ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext= ac_cv_func_connect=yes ac_cv_func_getbkgd=no ac_cv_func_gethostbyname=yes ac_cv_func_inet_aton=yes ac_cv_func_iswalnum=no ac_cv_func_remove=yes ac_cv_func_resizeterm=no ac_cv_func_shmat=yes ac_cv_have_x='have_x=yes ac_x_includes=/usr/X11R5/include ac_x_libraries=/usr/X11R5/lib' ac_cv_header_GL_gl_h=no ac_cv_header_GL_glx_h=no ac_cv_header_X11_XKBlib_h=no ac_cv_header_X11_Xlib_h=yes ac_cv_header_X11_Xutil_h=yes ac_cv_header_X11_extensions_XShm_h=yes ac_cv_header_X11_extensions_Xrender_h=no ac_cv_header_X11_extensions_Xvlib_h=no ac_cv_header_X11_extensions_shape_h=yes ac_cv_header_X11_extensions_xf86dga_h=no ac_cv_header_X11_extensions_xf86vmode_h=no ac_cv_header_alsa_asoundlib_h=no ac_cv_header_audio_audiolib_h=no ac_cv_header_inttypes_h=no ac_cv_header_jpeglib_h=no ac_cv_header_libaudioio_h=no ac_cv_header_machine_soundcard_h=no ac_cv_header_memory_h=yes ac_cv_header_ncurses_h=no ac_cv_header_soundcard_h=no ac_cv_header_stdc=yes ac_cv_header_stdint_h=no ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_asoundlib_h=no ac_cv_header_sys_soundcard_h=no ac_cv_header_sys_stat_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_unistd_h=yes ac_cv_host=i386-pc-interix3 ac_cv_host_alias=i386-pc-interix3 ac_cv_lib_ICE_IceConnectionNumber=no ac_cv_lib_Xext_XShapeQueryExtension=yes ac_cv_lib_Xext_XShmQueryExtension=no ac_cv_lib_cups_cupsGetPPD=no ac_cv_lib_fl_yywrap=no ac_cv_lib_freetype_FT_Init_FreeType=no ac_cv_lib_i386_i386_set_ldt=no ac_cv_lib_l_yywrap=yes ac_cv_lib_m_sqrt=yes ac_cv_lib_mmap_mmap=no ac_cv_lib_ossaudio__oss_ioctl=no ac_cv_lib_w_iswalnum=no ac_cv_lib_xpg4__xpg4_setrunelocale=no ac_cv_mmap64_works=yes ac_cv_objext=o ac_cv_path_LDCONFIG=true ac_cv_path_install='/bin/install -c' ac_cv_prog_C2MAN='$(TOPSRCDIR)/tools/c2man.pl' ac_cv_prog_CPP='gcc -E' ac_cv_prog_LEX=lex ac_cv_prog_XLEX=lex ac_cv_prog_XYACC=yacc ac_cv_prog_ac_ct_AR=ar ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_DLLWRAP=false ac_cv_prog_ac_ct_LD=ld ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_ac_ct_STRIP=strip ac_cv_prog_ac_ct_WINDRES=false ac_cv_prog_cc_g=yes ac_cv_prog_lex_root=lex.yy ac_cv_prog_lex_yytext_pointer=yes ac_cv_prog_make_make_set=yes ac_cv_prog_sane_devel=no wine_cv_msg_freetype=no wine_cv_toolsdir='$(TOPOBJDIR)' wine_cv_warn_cups_h=no ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "Wine" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "20020904" #define PACKAGE_STRING "Wine 20020904" #define PACKAGE_BUGREPORT "" #define YYTEXT_POINTER 1 #define HAVE_LIBM 1 #define HAVE_GETHOSTBYNAME 1 #define HAVE_CONNECT 1 #define HAVE_INET_ATON 1 #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_UNISTD_H 1 #define HAVE_X11_XLIB_H 1 #define HAVE_X11_EXTENSIONS_XSHM_H 1 #define HAVE_X11_XUTIL_H 1 #define HAVE_X11_EXTENSIONS_SHAPE_H 1 #define HAVE_LIBXSHAPE 1 #define HAVE___VA_COPY 1 #define _FILE_OFFSET_BITS 64 #define __ASM_FUNC(name) ".def " __ASM_NAME(name) "; .scl 2; .type 32; .endef" #define __ASM_NAME(name) "_" name #define NEED_STDCALL_DECORATION 1 configure: exit 1

1 0

Re: Fixed selecting multiple files in common file dialog 95-style
by Duane Clark 15 Sep '02

15 Sep '02

Josef Meixner wrote: > Problem: > Selecting multiple files in an OpenDialog resulted in a crash, tested with > PVAstrumento. > > Changelog: > dlls/commdlg/filedlg95.c: > - Initializing the return-string shouldn't change the pointer. > - Added "FIXME" for case not handled. > - Directory and the filenames have to be separated by "\0". > - Added check to handle possible signed/unsigned overflow. > > Index: dlls/commdlg/filedlg95.c > =================================================================== > RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v > retrieving revision 1.80 > diff -r1.80 filedlg95.c > 1405c1405 > < ofn->lpstrFile = '\0'; > --- Hi Josef, and Juraj too, if you are reading this. Please create a file ~/.cvsrc and add the entry "diff -u", so that patches will be in unified diff format. Thanks.

1 0

Re: Fixed typo error in wingdi.h, added structure tags in winbase.h
by Francois Gouget 15 Sep '02

15 Sep '02

On Sun, 15 Sep 2002, Juraj Hercek wrote: > Hi everybody, > I was permanently fixing COLORREF in wingdi.h after every update of > wine snapshot. I hope, I'll never have to do it again :o). I needed also > some tags to be defined in structures in winbase.h file. Hmm, apparently the patch is missing so I'm afraid you will have to keep patching things ;-) Unless you resubmit with the patch of course. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

Re: Shell execute with URLs
by Eric Pouech 15 Sep '02

15 Sep '02

Duane Clark a écrit : > > I finally managed to test the shell execute functions with URLs. why do you call WaitForInputIdle through a pointer ? loader needs to do it because of DLL separation (loader belongs to kernel32, and thus cannot call user32) your code lives in shell32, which already loads user32, so direct call would do A+

2 1

Problem with the TEB parser
by Sylvain Petreolle 15 Sep '02

15 Sep '02

Hi list, I encounter problem with the TEB parser. Enabling the builtin olepro32 and run winedbg on a program that needs it stops with following errors hen halting on a read access to 0x0. what could I do to debug this ? First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:04c7 EIP:00000000 ESP:405c25f0 EBP:4000b6c9 EFLAGS:00010206( R- 00 I - -P1 ) EAX:400136bc EBX:400134c0 ECX:4000bd00 EDX:400136bc ESI:00000000 EDI:00000000 Stack dump: 0x405c25f0 (NTDLL.DLL.sqrt+0x396ccc): *** Invalid address 0x405c25f0 (NTDLL.DLL.sqrt+0x396ccc) 0011: sel=008f base=4013e0c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x00000000 (ebp=4000b6c9) Can't read TEB:cur_stack 0x00000000: *** Invalid address 0x00000000 -- no code -- ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

UML Merged Into 2.5.34 , VxD's
by Thomas Wickline 14 Sep '02

14 Sep '02

I see UML made it into the 2.5.34 kernel http://user-mode-linux.sourceforge.net/ From what I get VxD drivers try to get hold of your pci bus and a ton of other stuff . Could this be the start to a fix down the road when it comes to .vxd support ? Will this help when it comes to a Wine Kernel Module ? cut from there site --- User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software. ----- Tom

6 6

Regitry Load*RegistryFiles options oboleted?
by Raul Dias 14 Sep '02

14 Sep '02

Hi, Did the regsitry section options: LoadGlobalRegistryFiles and LoadHomeRegistryFiles got obsoleted? It is not in misc/registry.c or anywhere else in the source other than in documentation dir. When was it obsoleted? why? Regards, Raul Dias

1 1

Re: recognize Unix-style hidden files
by Alexandre Julliard 14 Sep '02

14 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > The semantics associated in Unix with files starting with > a . is that they are hidden, *exactly* like the hidden DOS > files. We should mark them as such. > > We're lucky in that the DOS world does not use files that > only have extension, so we have no semantical conflict. I don't think I agree with that. Maybe in the days of 8.3 files yes, but nowadays Windows apps can create files starting with a dot, and they don't expect these files to be hidden. Also hidden files are much harder to access under Windows than dot files under Unix, so I'm not sure it would really be better for the user. -- Alexandre Julliard julliard(a)winehq.com

5 12

Press: LinuxPlanet makes a great case for Wine
by Francois Gouget 14 Sep '02

14 Sep '02

(and reviews CrossOver Office 1.2 too :-) * August 29, 2002 - LinuxPlanet CrossOver Office: Cutting to the Quicken http://www.linuxplanet.com/linuxplanet/reviews/4405/1/ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

1 0

Re: wine/ dlls/ntdll/Makefile.in win32/device.c me ...
by Dimitrie O. Paun 13 Sep '02

13 Sep '02

On September 13, 2002 02:52 pm, Alexandre Julliard wrote: > Log message: > Copied the registry functions needed by VMM into device.c and got rid > of memory/registry.c. Hmm, this is painful. Why and how long do we have to support Win95 advapi32? -- Dimi.

2 2

Re: Re:can windows be reparented?
by Dmitry Timoshkov 13 Sep '02

13 Sep '02

<us(a)the-edmeades.demon.co.uk> wrote: > To be honest I never investigated further once I commented out the SetParent call, > as I was continuing to fix oleaut32 and left the gui side to someone else! > > I know it was being called in the failing case, and removing it allowed the > windows to pop up, BUT they were still wrong as you could access the 'parent' > whereas you should not be able to Could you please test patch posted by Bill Medland to wine-patches today? It's not entirely correct though. My tests show that SetWindowLong(GWL_HWNDPARENT) call changes simultaneously both parent and owner for top level windows and returns old value (not sure old owner or parent it is). But top level windows created by Visual Vasic are special: they have no parent, but only owner according to Spy++. In my tests I can't reproduce it yet. A bit of investigation of Wine source revealed that some places use GetAncestor(hwnd, GA_PARENT), while others use GetParent(hwnd). Since their behaviour is different in respect of top level and child windows, some major clean up in that area in Wine is needed. -- Dmitry.

4 5

Winemaker broken?
by steve.lustbader＠philips.com 13 Sep '02

13 Sep '02

Winemaker doesn't work in the latest CVS. When I run it, it tells me: Global symbol "$app_name" requires explicit package name at /usr/local/bin/winemaker line 1674. Execution of /usr/local/bin/winemaker aborted due to compilation errors. It worked as of Sept 10. -Steve

2 2

configure and then make distclean
by Shachar Shemesh 13 Sep '02

13 Sep '02

Hi, For some strange reason (well, maybe not strange), I cannot run "make distclean" unless the make files are up to date. Is there a reason for this, or is this just a result of a check at the very begining of the makefile? It seems rather strange to me to do "./configure && make distclean; ./configure && make depend && make". Shachar P.S. No, I am not doing this every single time.

2 1

Re: Winemaker: improved MSVCRT support
by Francois Gouget 13 Sep '02

13 Sep '02

On 13 Sep 2002, Martin Wilck wrote: [...] > + if ($dllname =~ /^msvcrt\.dll$/) { You can also say 'if ($dllname eq "msvcrt.dll")'. Great work on winemaker :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

1 0

Re: Improved MoveFileEx() Patch
by Huw Davies 13 Sep '02

13 Sep '02

On Fri, Sep 13, 2002 at 04:50:47PM +0200, Martin Wilck wrote: > Index: files/file.c > =================================================================== > RCS file: /home/wine/wine/files/file.c,v > retrieving revision 1.160 > diff -u -r1.160 file.c > --- files/file.c 12 Sep 2002 22:28:01 -0000 1.160 > +++ files/file.c 13 Sep 2002 14:26:47 -0000 > @@ -2579,6 +2579,7 @@ > { > DOS_FULL_NAME full_name1, full_name2; > HANDLE hFile; > + DWORD attr = INVALID_FILE_ATTRIBUTES; > > TRACE("(%s,%s,%04lx)\n", debugstr_w(fn1), debugstr_w(fn2), flag); > > @@ -2619,8 +2620,7 @@ > /* target exists, check if we may overwrite */ > if (!(flag & MOVEFILE_REPLACE_EXISTING)) > { > - /* FIXME: Use right error code */ > - SetLastError( ERROR_ACCESS_DENIED ); > + SetLastError( ERROR_FILE_EXISTS ); > return FALSE; > } > } > @@ -2647,17 +2647,17 @@ > return FILE_AddBootRenameEntry( fn1, fn2, flag ); > } > > + attr = GetFileAttributesA( full_name1.long_name ); Any reason why you don't use: attr = GetFileAttributesW( fn1 ); here? I've seen cases that I've not had time to investigate where the former version fails. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Shell icons - legal
by Jacek Bator 13 Sep '02

13 Sep '02

Hello! I realy don't like icons which are currently in shell32.dll. I've created few replacement icons from there. They are much more simillar to win95,98 icons ... but not exactly the same. I want to confirm that my work will not be wasted. ---- Original icons from Windows shell32.dll can't be inserted in wine dll because of legal issues (design or something). ----- If I'm wrong let me know. Jacek Bator jbator(a)ecommercelogic.com

1 0

WM_PAINT disappeared
by Fabian Cenedese 13 Sep '02

13 Sep '02

Hi all I have a problem with my MFC-MDI-app. There are some other windows docked in the main window. The problem now is that they don't get painted. I end up with an app-window with some areas that never get updated. I first tried with tracing but I never saw anything wrong. Now I logged in my child window (CIXDockWnd) all messages it gets. This is what happens at creation in Windows: CMainFrame::OnCreate CIXDockWnd: -WM_NCCREATE -WM_NCCALCSIZE -WM_CREATE -WM_SIZE -WM_MOVE .. (some other stuff) -WM_WINDOWPOSCHANGING -WM_NCCALCSIZE -WM_WINDOWPOSCHANGED -WM_SIZE -WM_SHOWWINDOW CImdApp::InitInstance: Call ShowWindow CImdApp::InitInstance: Call UpdateWindow CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) CImdApp::InitInstance: Call SetFocus CIXAppFrame::OnWindowPosChanged CIXDockWnd: -WM_PAINT (*) -WM_NCPAINT (*) -WM_ERASEBKGND (*) IDLE_UPDATE Here the window is finished and visible, waiting for actions. In Wine though the paint messages of the child window (*) never show up, it stays clear. I don't know now if this is a problem in message routing (I don't think so as all other messages come through) or if these messages aren't sent at all. To investigate this can somebody point me to directions where these messages should be generated? Thanks bye Fabi

1 0

Tagging releases
by Shachar Shemesh 13 Sep '02

13 Sep '02

Hi, Would it be possible to tag each "release" announced to wine-announce in the CVS, so cvs co -r WINE_20020702 wine will actually get the wine version that corresponds to that release? I know I can do "cvs co -D 2002-jul-02 wine" for similar effect, but I don't like that solution. It has not worked well for me, and it leaves some inclarities regarding files that had several commits on the same day (not to mention time zones etc.) Shachar

2 1

Re: Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA
by Andreas Mohr 13 Sep '02

13 Sep '02

On Thu, Sep 12, 2002 at 08:38:09PM +1000, Michael Beach wrote: > Recently I've been using WINE to run a Win32 exe which needs to load certain > DLLs which are located in the same directory as the exe. I was most perplexed > when I found that this worked initially, but when I moved the exe and DLLs to > a different directory it stopped working ie WINE would refuse to start the > exe, claiming that it was unable to load the required DLLs. > > After some debugging, I discovered that the critical factor was the length of > the pathname to the exe, when it passed a certain length it stopped working. > However this length was way short of the MAX_PATH value of 260. Ah, cool finding ! > static BOOL DIR_TryModulePath( LPCWSTR name, DOS_FULL_NAME *full_name, BOOL win32 ) > { > - /* FIXME: for now, GetModuleFileNameW can't return more */ > - /* than OFS_MAXPATHNAME. This may change with Win32. */ > - WCHAR bufferW[OFS_MAXPATHNAME]; > + WCHAR bufferW[MAX_PATH]; > LPWSTR p; > > if (!win32) > @@ -727,13 +725,13 @@ > if (!GetCurrentTask()) return FALSE; > if (!GetModuleFileName16( GetCurrentTask(), buffer, sizeof(buffer) )) > return FALSE; > - MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, OFS_MAXPATHNAME); > + MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, MAX_PATH); > } else { > - if (!GetModuleFileNameW( 0, bufferW, OFS_MAXPATHNAME ) ) > + if (!GetModuleFileNameW( 0, bufferW, MAX_PATH ) ) > return FALSE; > } > if (!(p = strrchrW( bufferW, '\\' ))) return FALSE; > - if (OFS_MAXPATHNAME - (++p - bufferW) <= strlenW(name)) return FALSE; > + if (MAX_PATH - (++p - bufferW) <= strlenW(name)) return FALSE; > strcpyW( p, name ); > return DOSFS_GetFullName( bufferW, TRUE, full_name ); Argl, why does this code use the buffer size contants instead of sizeof(variable) !? I suggest we always specify buffer length constants only *once*, namely at creation of the buffer. Not doing so can be potentially very harmful if we decide to change the buffer length and then manage to forget one or more length constants... Maybe you could even also fix that "weirdness" in our code ? Thanks ! :) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

4 8

Re: WineLib and DLLs
by steve.lustbader＠philips.com 13 Sep '02

13 Sep '02

If possible, I don't want to insert it into the wine tree, I want to leave it in the source tree of my program. Is including it in the wine tree the only way to link with it? -Steve Jon Griffiths <jon_p_griffiths To: Steven Edwards <steven_ed4153(a)yahoo.com> @yahoo.com> cc: wine-devel(a)winehq.com Sent by: (bcc: Steve Lustbader/ANR/MS/PHILIPS) wine-devel-admin Subject: Re: WineLib and DLLs @winehq.com Classification: 09/12/2002 05:58 PM Please respond to jon_p_griffiths Hi, >I'm writing a WineLib DLL that makes calls in my own Windows DLLs >(not Wine's DLLs). I have the header files for those DLLs, and the >Windows binaries for them. How do I link to them? Do I need to wrap >them in spec files? What do I need to put into my Makefile.in? look at tools/winedump. In spec mode it will generate everything you need to link to this dll - a makefile and dummy implementation, spec file and a script to insert it into your existing WINE tree (to link with). The README gives instructions for exactly this case (and some other more advanced ones). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

re: shlwapi failes to build on windows
by Jon Griffiths 12 Sep '02

12 Sep '02

Hi, >shlwapi.exp(.edata+0x34):fake: undefined reference to >`AssocCreate@12' >C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 >make: *** [shlwapi.dll] Error 1 >The def should contain AssocCreate@24 I do not know what is needed >in the *.spec though This is due to the spec entry possibly being incorrect. AssocCreate takes a CLSID as its first parameter (rather than a ptr to one as any sane coder would have expected). I have no idea how to tell the spec file that the first parameter is a structure, however this obviously means that the size of the parameters listed after the '@' is wrong. I'm not sure how to fix this, since passing structs is a rare case, I've never looked into how to specify them in the spec. Maybe we need a "struct(n)" spec type for by value structures? Another note: if you're planning to try to test SHLWAPI under Windows you should be running NT 4 or later, as there are some changes needed w.r.t unicode to get earlier O/Ss working OK. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 2

Fwd: Message Undeliverable
by Dimitrie O. Paun 12 Sep '02

12 Sep '02

This is the second (and I have a third now) message of this type that I receive, even though it seems that my messages to reach the list. What's up? ---------- Forwarded Message ---------- Subject: Message Undeliverable Date: Thu, 12 Sep 2002 15:40:19 -0600 From: postmaster(a)www.praize.com To: dpaun(a)rogers.com User does not exist Message Headers: Return-Path: <wine-patches-admin(a)winehq.com> Received: from admin.praize.com (root@localhost) by praize.com (8.11.6/8.11.6) with ESMTP id g8CLcxP18778 for <gboutwel(a)praize.com>; Thu, 12 Sep 2002 15:38:59 -0600 X-ClientAddr: 198.144.4.3 Received: from wine.codeweavers.com (wine.codeweavers.com [198.144.4.3]) by admin.praize.com (8.11.6/8.11.6) with ESMTP id g8CLcwD18774 for <gboutwel(a)praize.com>; Thu, 12 Sep 2002 15:38:58 -0600 Received: from localhost.localdomain (wine [127.0.0.1]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id g8CLb6F27723; Thu, 12 Sep 2002 16:37:06 -0500 Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id g8CLaeF27686 for <wine-patches(a)winehq.com>; Thu, 12 Sep 2002 16:36:41 -0500 Received: from dimi.dssd.ca ([24.103.156.204]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20020912213628.FCWQ389684.fep04-mail.bloor.is.net.cable.rogers.com(a)dimi.dss d.ca> for <wine-patches(a)winehq.com>; Thu, 12 Sep 2002 17:36:28 -0400 Content-Type: text/plain; charset="us-ascii" From: "Dimitrie O. Paun" <dpaun(a)rogers.com> Organization: DSSD Software Inc. To: Wine Patches <wine-patches(a)winehq.com> Subject: Trackbar updates User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209121734.32094.dpaun(a)rogers.com> X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.156.204] using ID <dpaun(a)rogers.com> at Thu, 12 Sep 2002 17:36:27 -0400 Sender: wine-patches-admin(a)winehq.com Errors-To: wine-patches-admin(a)winehq.com X-BeenThere: wine-patches(a)winehq.com X-Mailman-Version: 2.0 Precedence: bulk Reply-To: wine-devel(a)winehq.com X-Reply-To: dpaun(a)rogers.com List-Help: <mailto:wine-patches-request@winehq.com?subject=help> List-Post: <mailto:wine-patches@winehq.com> List-Subscribe: <http://www.winehq.com/mailman/listinfo/wine-patches>, <mailto:wine-patches-request@winehq.com?subject=subscribe> List-Id: Wine Patch Submissions <wine-patches.winehq.com> List-Unsubscribe: <http://www.winehq.com/mailman/listinfo/wine-patches>, <mailto:wine-patches-request@winehq.com?subject=unsubscribe> List-Archive: <http://www.winehq.com/hypermail/wine-patches/> Date: Thu, 12 Sep 2002 17:34:31 -0400 Status: ------------------------------------------------------- -- Dimi.

2 1

Re: WineLib and DLLs
by Jon Griffiths 12 Sep '02

12 Sep '02

Hi, >I'm writing a WineLib DLL that makes calls in my own Windows DLLs >(not Wine's DLLs). I have the header files for those DLLs, and the >Windows binaries for them. How do I link to them? Do I need to wrap >them in spec files? What do I need to put into my Makefile.in? look at tools/winedump. In spec mode it will generate everything you need to link to this dll - a makefile and dummy implementation, spec file and a script to insert it into your existing WINE tree (to link with). The README gives instructions for exactly this case (and some other more advanced ones). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Re: SHLWAPI merging #4
by Alexandre Julliard 12 Sep '02

12 Sep '02

Jon <jon_p_griffiths(a)yahoo.com> writes: > Does anyone object to my moving SHLWAPI_1 & 2 into url.c and moving out the > definitions from ordinal.h in there as well? > > I want to tidy this up because at some point in the not too distant future the > ordinal code will get a lot bigger. So it makes sense to me to implement > ordinals that are related in the same files (like the MIME ord. functions in > url.c), and to split out other ord. groups (gdi/windows/com/ie/perfmon etc) > into their own files as well. OK? Actually there's no reason at all to group ordinal functions together, the fact that they are exported by ordinal is just a detail that doesn't matter for understanding what's going on. It's much better to group ordinal string functions with other string functions, ordinal URL functions with other URL stuff etc. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I also have the .lib and .pdb files for the DLLs, if that helps. I'm writing a WineLib DLL that makes calls in my own Windows DLLs (not Wine's DLLs). I have the header files for those DLLs, and the Windows binaries for them. How do I link to them? Do I need to wrap them in spec files? What do I need to put into my Makefile.in? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I'm writing a WineLib DLL that makes calls in my own Windows DLLs (not Wine's DLLs). I have the header files for those DLLs, and the Windows binaries for them. How do I link to them? Do I need to wrap them in spec files? What do I need to put into my Makefile.in? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Thanks, that worked! Do you think you could update the Unicode section in the WineLib user's guide (section 2.2)? It doesn't even mention WINE_UNICODE_NATIVE (not like the rest of the guide is that current, but every little bit helps for new developers). -Steve On Thu, 12 Sep 2002 steve.lustbader(a)philips.com wrote: > I think there is issue with _T(x). I have this line in my Windows app > that I'm compiling with WineLib (I'm using -fshort-wchar): > > const TCHAR *Name() const { return _T("my_name"); }; > > The compiler gives me an error of: > > cannot convert `const __wchar_t *' to `const > TCHAR *' in return If you are using --fshort-wchar you should also use WINE_UNICODE_NATIVE so that WCHAR gets defined to wchar_t. From winnt.h: #ifdef WINE_UNICODE_NATIVE typedef wchar_t WCHAR, *PWCHAR; #else typedef unsigned short WCHAR, *PWCHAR; #endif and further down: /* Define WINE_UNICODE_NATIVE if: * - your compiler provides a 16bit wchar_t type, e.g. gcc >= 2.96 with * -fshort-wchar option * - or if you decide to use the native 32bit Unix wchar_t type. Be aware * though that the Wine APIs only support 16bit WCHAR characters for * binary compatibility reasons. * - or define nothing at all if you don't use Unicode, and blissfully * ignore the issue :-) */ Does that help? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels

1 0

shlwapi failes to build on windows
by Steven Edwards 12 Sep '02

12 Sep '02

shlwapi.exp(.edata+0x34):fake: undefined reference to `AssocCreate@12' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [shlwapi.dll] Error 1 The def should contain AssocCreate@24 I do not know what is needed in the *.spec though Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I think there is issue with _T(x). I have this line in my Windows app that I'm compiling with WineLib (I'm using -fshort-wchar): const TCHAR *Name() const { return _T("my_name"); }; The compiler gives me an error of: cannot convert `const __wchar_t *' to `const TCHAR *' in return It similarly complains about converting _T("foo") to a const WCHAR *. Both of these things work under Windows. Changing the definition of _T(x) from L##x to (TCHAR *) L##x avoids these problems, but then something like _T("foo") _T("bar") doesn't concatenate those strings like it does in Windows. -Steve --- steve.lustbader(a)philips.com wrote: > Are _tprintf and it's related functions (_ftprintf, > _stprintf) implemented? I found a tchar.h in the > source tree that defines these functions, but it > wasn't in my /usr/local/include/wine directory. I'm fixing the build process to install the header. For now you can copy it manually to the /usr/local/include/wine directory. Actually _ftprintf and _stprintf are not functions, but macros which are mapped in tchar.h to corresponding ASCII or Unicode function. The underlying functions should be implemented. > These functions aren't important for wine, since > they're simply defined as the ASCII or Unicode > version, but they are important for WineLib. > > What is the overall status of using Unicode with > WineLib? What needs to be defined and what headers > need to be included to get the functionality from > Windows' tchar.h (_T(), TCHAR, the above functions, > etc)? Unicode is supported relatively well in Wine. Please report if you have any issues with it. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

3 2

RE: wstr vs ptr in spec files
by Patrik Stridvall 12 Sep '02

12 Sep '02

> When should I use wstr and when ptr for wide strings > in the spec files functions specification? > > Looking at existing files I see that LPCWSTR type is > usually mapped to wstr, It should almost always map to wstr. > but LPWSTR is sometimes mapped > to ptr, sometimes to wstr. As the general rule it depends on whether the parameter is IN, OUT or IN/OUT. IN: wstr OUT: ptr IN/OUT: wstr PS. It is for debug messages. If the parameter is OUT it might not be initialized as thus it should not be printed as a string (in this case a wide string).

1 0

Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Are _tprintf and it's related functions (_ftprintf, _stprintf) implemented? I found a tchar.h in the source tree that defines these functions, but it wasn't in my /usr/local/include/wine directory. These functions aren't important for wine, since they're simply defined as the ASCII or Unicode version, but they are important for WineLib. What is the overall status of using Unicode with WineLib? What needs to be defined and what headers need to be included to get the functionality from Windows' tchar.h (_T(), TCHAR, the above functions, etc)? -Steve

3 2

wstr vs ptr in spec files
by Andriy Palamarchuk 12 Sep '02

12 Sep '02

When should I use wstr and when ptr for wide strings in the spec files functions specification? Looking at existing files I see that LPCWSTR type is usually mapped to wstr, but LPWSTR is sometimes mapped to ptr, sometimes to wstr. Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

RE: Patch - Fix typo
by Patrik Stridvall 12 Sep '02

12 Sep '02

> On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > > I noticed this when adapting WINE code for ReactOS > [...] > > > > - * DialogBoxIndirectParam (USER.240) > > > - * DialogBoxIndirectParam16 (USER32.@) > > > + * DialogBoxIndirectParam16 (USER.240) > > > + * DialogBoxIndirectParam (USER32.@) > > > */ > > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > > HANDLE16 dlgTemplate, > > > HWND16 owner16, > > > DLGPROC16 dlgProc, > > > > No this is correct. > > > > The 16 bit function's external name is DialogBoxIndirectParam > > The 32 bit function's external name is DialogBoxIndirectParam16 > Then maybe add a comment instead: > "(yep, 16/32 naming is correct)" Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.

1 0

Re: Patch - Fix typo
by Andreas Mohr 12 Sep '02

12 Sep '02

On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > I noticed this when adapting WINE code for ReactOS [...] > > - * DialogBoxIndirectParam (USER.240) > > - * DialogBoxIndirectParam16 (USER32.@) > > + * DialogBoxIndirectParam16 (USER.240) > > + * DialogBoxIndirectParam (USER32.@) > > */ > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > HANDLE16 dlgTemplate, > > HWND16 owner16, > > DLGPROC16 dlgProc, > > No this is correct. > > The 16 bit function's external name is DialogBoxIndirectParam > The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: "(yep, 16/32 naming is correct)" -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun 12 Sep '02

12 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > Alexandre: Is this format any better. I am worried about line end > characters and line wrapping. I like this format a lot better! But I'm no Alexandre... :) > This is built on top of CVS of yesterday (9/9/02) but will probably > conflict with Dimi's latest patch. Can you please rediff against the current tree? TIA, Dimi.

3 5

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 12 Sep '02

12 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The orginal reason for winapi_cleanup was to convert the \r\n > > that I got while editing in Micrsoft Developer studio > > to \n. > > > > But I can modify it the so it only does that. > > > > It should probably remove trailing whitespace at lines > > ending in \ though since some compilers choke on that. > > Sure, the idea of a cleanup tool is a good thing, it just should only > do the cleanups that we all agree on. Myself I'm especially interested > in an automatic cleanup of C++ comments... Already on my TODO list. BTW. How do you want multiliners like // XXX // YYY // ZZZ to look like? Like this /* XXX * YYY * ZZZ */ or like this /* * XXX * YYY * ZZZ */ or perhaps in some other way? One liners like // XXX should simply look like /* XXX */ Or would you prefer it some other way?

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > Well, the idea would be not to depend on compiler support for the > __declspec keyword itself, but more to have some clever macro > replacements that output stuff in a special ELF section or something > like that. This could then hopefully be made to work on most > compilers. But I'm not sure if there's a good way to do that at all. It might work, but then it might not. > > This isn't happend soon either. It might not be THAT difficult, > > however the code need not just work it needs be well structured > > and organized as well if any reasonable guarantees of correctness > > can be made. > > I think most of all it needs to be simple. My idea is to run through > the preprocessor, This will be VERY slow. > find the __declspec, and locate the corresponding > function name, or die if there's anything it cannot parse. This should > be reasonably foolproof. A naive idea would be search for __declspec while keeping track of the nesting level (that is how many (, [, { that have not been closed). If the nesting level goes from 1 to 0 before finding the __declspec set a mark. When __declspec is found search backward to mark until you find ; at nesting level 0 or the mark then skip forward any white space. This is extremely likely to be the beginning of a function. Then search forward until { or ; is found when nesting level is 0. Then skip any whitespace backwards. You now know where a __declspec function begins and ends. This reduces the problem to the parsing of a function declaration. The rest is left as an exersize to the reader. :-) The problem is that this might work or it might not. You have no real guarante that it will. > And IMO it shouldn't be in Perl, it should be > part of winebuild. That will not make things easier.

3 2

Strange CVS problem (help!!!)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Folks, Up until a few days ago, I was able to do this: # vim some/wine/file.c # cvs diff some/wine/file.c > file.diff # mail wine-patches(a)winehq.com < file.diff # sleep <until Alexandre commited the patch> # cvs up At this point, CVS would figure out that the changes in file.c in my tree are the same as the ones on the server, will give a message to that effect, and update the file. As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different? -- Dimi.

7 20

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > I (personally) like to keep it the way it is. > > If the submitter is worried about the spaces he can > > run the whitespaces cleaning tool himself before > > submitting the patch (hint, hint ;-) > > Well, no, if not everybody does it you can't do it either, otherwise > it will create huge differences. I don't want to receive a patch that > is 10% code and 90% whitespace changes just because the guy who edited > the file before you didn't cleanup the spaces. Well, either you remove trailing whitespaces from patches or you don't. If you do than "the guy who edited the file before you didn't cleanup the spaces" case can't happend, can it?

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> > You have the case: > > void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) > > __attribute__((noreturn)) { } > > > > Sure you can have an exception if the name seems to be > __attribute__ but > > then where might be other exceptions. > > Yes, but a few preprocessor defines can get rid of that. Well. You want to read the __attribute__ to know if the function should be stdcall or cdecl don't you? The there might be cases I haven't though of. > > > The only problem is if you want to find > > > the number of args for stdcall decoration, but we should > be able to do > > > without it. > > > > That is not a problem. If you find the opening ( before the > function name, > > it would be the number of , at nesting level 1 plus one > with the special > > case of void between the parantesis which means 0. > > Except for 64-bit data types... And data structures. Forgot about that. > > Perhaps. You will easily reach 99% correctness. However > beyond that it > > is hard without a real C parser. > > Well it's clear you can't get 100%, the thing is to make sure it fails > in a reasonable way, not just silently breaks. Agreed. > I think it is feasible; Maybe. > whether it is worth the effort is an entirely different question... It is MANY hours of work. Work I'm not going to be able to motivate myself to do especially not if you want it in C. The last time years ago I did parsing and string handling in C was a horrible experience one I'm not eager to experience again, especially since other tools (read: Perl) exists. PS. I do agree it should be done in C though.

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will be VERY slow. > > I don't think it will be really different than duplicating all the > work the preprocessor is doing inside the parser itself. Of course you > want to use the Wine preprocessor, not fork+exec gcc for each file. OK. I was mainly refering to fork+exec gcc. > But yes parsing all the files is of course slower than having all the > info in the .spec, there's no way around that. Of course. > > You now know where a __declspec function begins and ends. > > This reduces the problem to the parsing of a function declaration. > > The rest is left as an exersize to the reader. :-) > > All you really need is the function name, which should be the last > token before the opening '('. Yes, but which opening? There might be several at nesting level 0. And searching backward to find the matching ( from the last ) might not be always correct either. You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { } Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions. > The only problem is if you want to find > the number of args for stdcall decoration, but we should be able to do > without it. That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0. > > The problem is that this might work or it might not. You > have no real > > guarante that it will. > > Well the thing is if you find a declspec you output what you think is > the function name. If you get it wrong and output 'WINAPI' or 'char*' > instead you'll notice it at build time. Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser. It easy to do that for reasonable functions but for ALL function is much harder. For example you have the special case of a function that returns a function pointer. Not even all C compilers gets that one right, so it normally done with a helping typedef...

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > Not quite. If you run the tool on every commit (which is in > effect what's > > happening now), you almost guarantee that many people > contributing code > > will experience conflicts on a *daily* basis. If you run > the tool once > > once a year, I will experience the conflict only then. And > I will be so > > much happy. > > Well yes, that's what I meant by saying that the tool is "useless". If > I'm the only one who can use it, and then only once a year, we don't > really need it. As I can see it either we enforce no trailing whitespace or we do not. I can't see any reasonable middle ground. I'm of course for no trailing whitespace. :-) However I'm not going to start a new flamewar other it... > And in fact we should probably remove it so that other > people are not tempted to use it... The orginal reason for winapi_cleanup was to convert the \r\n that I got while editing in Micrsoft Developer studio to \n. But I can modify it the so it only does that. It should probably remove trailing whitespace at lines ending in \ though since some compilers choke on that.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 01:51 pm, Alexandre Julliard wrote: > > And in fact we should probably remove it so that other > > people are not tempted to use it... > > As long as I don't have to deal with the conflicts. I had > only grief from removing the whitespace, and NO benefit. > For me, the choice is clear. Have you tried to run winapi_cleanup before submitting the patch or alternatively before running "cvs update"?

1 0

OfficeXP/IE and latest CVS wine
by Boris 11 Sep '02

11 Sep '02

I downloaded the latest wine cvs [09-11-2002] and not using any windows files. I tried installing OfficeXP and only when I set the OS to Winme, It continues the farthest until it starts installing and then it says the setup files are corrupted. I looked at my status window and it says fixme:advapi:SetThreadToken((nil_,cafe): stub (NT impl. only) fixme:setupapi:SetupIterateCabinetA not implemented (setupapi.dll) Ive noticed even when trying to install IE5 or 6 without any hacks, it seems that their are *alot* of things not implimented in the setupapi. It would be nice to get install IE 5 or 6 off a clean wine installation without hacking the configs or creating any extra directories.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > On September 11, 2002 12:58 pm, Alexandre Julliard > > wrote: > > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > > > Well, I'm happy to turn it off if people consider > > it to be a problem. > > > > I think it should be turned off. It causes a lot of > > grief, for very little > > gain, if any. Moreover, now you have a tool in the > > tree that does that > > automatically, and cleverly. > > > > If you think whitespaces are a problem, *you* apply > > it say, once a year. > > Or every 5 years, I don't care. > > I (personally) like to keep it the way it is. > If the submitter is worried about the spaces he can > run the whitespaces cleaning tool himself before > submitting the patch (hint, hint ;-) Exactly. :-)

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 11:07 am, Patrik Stridvall wrote: > > > Well as I said a lot of API use LPSTR when it really should > > use LPCSTR so the potential IO/OUT cases are quite a few. > > I don't think it's "lot". Can you give a count where LPSTR/LPWSTR > is used for a IN parameter only? I don't know how to do that automatically. You will have to look in the documentation and sometimes the documention is wrong... > And those we can fix in our > sources, as you said. Yes. > > You mean just add a OUT before the type. That is quite easy > to parse. > > Even better -- encode it in the typeinfo. > > /* M = modifiable */ > typedef LPSTR LPMSTR; > typedef LPWSTR LPMWSTR; > > Use LPM{,W}STR instead of LP{,W}STR where the parameter is an IO one. > The type are equivalent, so no one will notice a difference except > our parsing tool. I personally like the OUT better since it is official defined by Microsoft. > BTW, how many are IO? I would suspect most are O only... For strings, not that many. Can't think of any right now. However there are quite a few LPDWORD that specifies the allocated length of the output buffer and the function is should write the used length (or needed length, if the function faild) in the pointed to DWORD. Other than that it is quite uncommon IIRC.

3 2

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On Wed, 11 Sep 2002, Patrik Stridvall wrote: > [...] > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > I agree that Wine should not depend on hacked compilers. However it > would be nice to have anyway for Winelib. There should be an > alternative > but if it saves 'big' Winelib developpers from having to > write huge spec > files by hand then it would definitely be a plus. For Winelib sure that would be a good idea. > I'm not saying that you, Patrik, should do it. I just don't want > potential contributers to think that this is not something > that would be > useful to Wine/Winelib. OK. For the record I see absolutely nothing wrong GNU C handles __declspec(dll{import,export}) and just put useful information in some aproprietely named section. After all you can always strip the section if don't want it and BTW if why don't want it why use __declspec(dll{import,export}) at all...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> The parser shouldn't require any modification > to the source, and should work on any Windows source, not only the > Wine ones. This means there are basically two approaches: > > 1. write a full C compiler This isn't happening soon. Definitely not within the coming months and not likely this year and more likely than not neither the coming year. > 2. use Patrik's Perl stuff to generate the initial info as best as we > can and then update it by hand. > > IMO #2 is the way to go, because no matter how clever a parser you > write it won't be able to extract semantics information; and that > would be the main advantage of doing a better relay debugger. Imagine > dumping structure contents, flags, following list pointers, etc. We > shouldn't limit ourselves to what can be extracted automatically from > the source. Agreed. I can write code if you, Dimitrie or whomever specify the output format... > Of course having an imperfect parser also means we cannot use it for > the export info, because unlike relay debugging it needs to be 100% > correct. So we either need compiler declspec support, That will leave us dependent on compilers that support it. > or we need a > specialized tool to extract the declspec info in a way that is > guaranteed to not miss anything. This isn't happend soon either. It might not be THAT difficult, however the code need not just work it needs be well structured and organized as well if any reasonable guarantees of correctness can be made.

3 2

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Steven Edwards <steven_ed4153(a)yahoo.com> writes: > > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? > > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > > time getting Mingw+MSYS+Perl working and would hate to see > it become a bigger requirement. If > > -mno-cygwin worked right I dont guess it would be as big of > a deal because then we could still > > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > > of cygwin1.dll so the recommended setup is just Mingw+MSYS. > > Yes, we should try to move away from the Perl requirement for > regression tests. It was considered OK to depend on it because the > framework itself was based on Perl, but now that all tests are done in > C anyway we should probably get rid of it. I see no reason to get rid of it. If people doesn't have Perl installed just don't run them. But then most people probabably have Perl installed anyway...

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 10:23 am, Patrik Stridvall wrote: > > However how do know whether it is IN/OUT or OUT? > > Excellent point. There aren't that many IN/OUT cases anyway > (can you produce a count?), Well as I said a lot of API use LPSTR when it really should use LPCSTR so the potential IO/OUT cases are quite a few. > but we would need to add some > metainfo at the source level. No big deal, really... You mean just add a OUT before the type. That is quite easy to parse.

3 4

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> --- Patrik Stridvall <ps(a)leissner.se> wrote: > > > > > But beyond that, we can *today* compile Wine with > Mingw as PE. So > > > > > what we need is a checkspec make target which would run > > > your script, > > > > > compile Wine as PE, extract what needs extracting > from there, and > > > > > compare results. This does not need to happen all the > time, only > > > > > from time to time by some people that (1) have Mingw > installed, > > > > > and (2) care to do it :). > > > > > > > > True. However I still a little worried about the "stabillity" > > > > of the solution. > > > > > > Why? This is as good of a verification method (no, even > better) than > > > what we have today. > > > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > > > But I'm not really against it, I'm just pointing out > > potential problems... > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? It is not really dependent on Perl. Of course you can't run regression test written in Perl without Perl... > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > time getting Mingw+MSYS+Perl working and would hate to see it > become a bigger requirement. If > -mno-cygwin worked right I dont guess it would be as big of a > deal because then we could still > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > of cygwin1.dll so the recommended setup is just Mingw+MSYS. I understand. On the other hand we can't hold back "progress" just because of difficulties of installing certains tools on certain platforms. But judging from Alexandres message it won't be happing anytime soon... > Note: even using perl on cygwin is still borked atm for the > regression suite and I havent even > tried winapi_check. another option may be to look at active > perl for windows but I really dont > like that idea. ActivePython for Windows works nicely. Haven't tested ActivePerl...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> > > But beyond that, we can *today* compile Wine with Mingw as PE. So > > > what we need is a checkspec make target which would run > your script, > > > compile Wine as PE, extract what needs extracting from there, and > > > compare results. This does not need to happen all the time, only > > > from time to time by some people that (1) have Mingw installed, > > > and (2) care to do it :). > > > > True. However I still a little worried about the "stabillity" > > of the solution. > > Why? This is as good of a verification method (no, even better) than > what we have today. Sure, but I have written the Perl code I know how ad hoc it is. It works under reasonable assumptions however beyond that... But I'm not really against it, I'm just pointing out potential problems...

4 3

Standard controls
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

And since I feel frisky lately, I want to run another idea by you guys. We have the standard controls bundled with USER, just like Windows. In fact, it seems XP bundles them with the common control, but that's another story. My point is, that there's no logical reason they should be in USER. In fact, in the future we may want to provide other implementations which integrate better with GNOME and/or KDE. So what about moving them to a separate DLL, say winectrl? -- Dimi.

2 2

winebuild & (name, heap, init)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Alexandre, Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)? Some of them are supported in .DEF file as well, but all of them are supported as arguments to LINK. I think it will gain us flexibility if we also support them as command line arguments. With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out... Anyway, what about a patch to at least support all of this as command line options as well? -- Dimi.

4 7

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 11:33 am, Patrik Stridvall wrote: > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > But we don't *want* Wine's sources to look beyond reasonable. > I see no problem. Even better, if this helps us detect unreasonable > looking sources... Well winapi_check already does that so no additional advantage...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dpaun@rogers.com] > Sent: Wednesday, September 11, 2002 5:37 PM > To: Patrik Stridvall; Francois Gouget > Cc: Wine Devel > Subject: Re: winebuild & (name, heap, init) > > > On September 11, 2002 11:24 am, Patrik Stridvall wrote: > > > BTW, how many are IO? I would suspect most are O only... > > > > For strings, not that many. Can't think of any right now. > > However there are quite a few LPDWORD that specifies the > > allocated length of the output buffer and the function > > is should write the used length (or needed length, > > if the function faild) in the pointed to DWORD. > > Dude, you're killing me! I often do that yet you still live. :-) > We care to distinguish I/O for strings _only_. And since we > don't have any, we have no problem!!! We have I found an example: LPTSTR PathAddBackslash(LPTSTR lpszPath); A few more of the Path functions are like that IIRC. Then there might be more function. The Windows API is larger we have only begun to implement it... > For LPDWORD, print them > always, they are fixed length, you (as the guy looking at the > traces) know if you care about them or not... True. How if you wish to automatically compare debug output diffs you have a problem. Sure pointer and such usually differs but that can be fixed with some sort of mapping table. However the value of unintialized variables are "random" or rather non-derministic since they might depend of subtle differences in the enviroment. But I do agree that strings is the larger problem...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Were we distinguishing IN/OUT and OUT before in the spec file? No. I suggest to Alexandre that we should add such information but he rejected my patch...

1 0

RE: winebuild & (name, heap, init)
by Jeff Smith 11 Sep '02

11 Sep '02

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 10:16 am, Patrik Stridvall wrote: > > #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) > > > > FOO(Bar, INT, HWND) { > > /* ... */ > > } > > > > But we don't need to support that. If it doesn't get recognized, > the function is not exported. You can manually look in the generated > spec file and see it's not there. > > I don't think we need to be too clever. Just get the 80% that can be > done with 20% of effort. Well as I said "winapi_extract --spec-files" works to some extent even now and getting it to work good enough might not be that much effort. However I'm worried about the "stabillity" of the result. > It's a temporaray solution anyway: we need > help from the compiler, writing a C parser (no, a gcc-C parser) is > a lot of work. Yes. I know I have tried. :-) > Mingw supports __declspec, Urlich, what would it take > for the regular gcc to support it under Linux/ELF? But what should it do? Just generate a special dllexport section that you can read with appropriate tools or what? > But beyond that, we can *today* compile Wine with Mingw as PE. So > what we need is a checkspec make target which would run your script, > compile Wine as PE, extract what needs extracting from there, and > compare results. This does not need to happen all the time, only > from time to time by some people that (1) have Mingw installed, > and (2) care to do it :). True. However I still a little worried about the "stabillity" of the solution.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 05:48 am, Francois Gouget wrote: > > Hmm, for strings the spec files currently distinguish between input > > strings (str) and output strings (ptr). This cannot be > extracted from > > the source files... unless we start using IN/OUT macros everywhere? > > It's all in the types, dude... > > LPCSTR/LPCWSTR = IN, LPSTR/LPWSTR=IN/OUT. The is almost always correct. Unfortunately Microsoft is not consequent in the regard, but then I guess that we could modify the API slightly. If a WineLib application breaks, it was in some meaning broken anyway. However how do know whether it is IN/OUT or OUT? For debug messages that is quite important since the pointer in the OUT case might point to uninitialized memory which shouldn't be printed in the debug output...

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 06:18 am, Patrik Stridvall wrote: > > However I might be able to write a very specialized parser, that > > pipes the .c files through the C preprosessor, that work all of the > > time, but this is quite some work as well. > > But we shouldn't need that. Wine has a very good strucutre right now, > and were that's broken, we can fix... Sure. But what would tell you that it was broken? winapi_check currently, among other thing, compares the .spec files with the source code. When it reports something there are three possibillities 1. winapi_check is broken (because the code doesn't have good structure) 2. the .spec file is broken 3. the .c file is broken Currently I check manually and I try to make an educated guess of which is the cases and then fix it. If you extract the information from the source you don't have that luxury. If it misses a function or have some other bug you have no backup. Since the .spec files exists winapi_check knows what functions it is expected to find in the source code and if is doesn't it reports it. So if for example we have function Foo that looks like. #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) FOO(Bar, INT, HWND) { /* ... */ } winapi_check will miss it (since it in an ad hoc parser), but since Bar is declared in some .spec file it will complain that Bar was never found. Then I manually search the source, and try to fix the problem somehow. If you on the other hand extract the .spec files (of .def files) from the source the function Bar would be missed and you would never detect it... That is why the parser needs to be so good that it "always" works.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 10, 2002 02:15 pm, Alexandre Julliard wrote: > > > Well, the problem is that the __declspec stuff is usually inside > > macros, so you have to run the code through the C > preprocessor to find > > them. It can be done, but it's not that trivial. Also one thing you > > need to extract is the relay debugging information (and for 16-bit > > code information for the relay routines), and this requires > a C parser > > (or some of Patrik's magic Perl stuff). > > I'm sure if we have the political will at the top, we'll find a > solution... :) Patrik, care to help us extract the required stuff > directly out of the source file? Sure. BTW winapi_extract can already do that: winapi_extract --spec-files This generates a .spec2 file that should hopefully be the same as the .spec file. It currently isn't (except for a few files) though but that can hopefully be fixed. Outputing in another format like .def files or whatever should be quite easy. However note that winapi_extract is quite ad hoc and specfic for parsing the Wine source tree. It is not a generalized C parser. I have begun with a generalized C parser in winapi_fixup however it doesn't quite work that good yet. Parsing generalized C is non trivial. > > A related idea I had is to store the relay debugging independently > > from the .spec file; you could then use it in other cases, notably > > with snoop debugging of native dlls. And then you no longer need a > > .spec, you can use a .def or directly extract the __declspecs, at > > least for Win32. This would also potentially allow more intelligent > > relay routines, maybe even per-dll relay code that knows > about the dll > > internal data structures; and hopefully also relay debugging of COM > > interfaces. > > Exactly! That's where I was driving at. But this depends on getting > stuff automatically out of .c file, because this way we can retain > the type information, which we now lose (except for strings). Once > we have the type information, the sky's the limit... But most > imprtantly, > we eliminate (1) a potential source of mistakes, (2) a barrier for > new commers (which are likely to be from the Windows world), and > (3) avoid maintenaning the 700KB of .specs!!! Agreed, but the script that does it is also a potential source of mistake and the current state of the winapi tools are that they work MOST of the time. However if we are to replace the .spec files it must work ALL the time. However I might be able to write a very specialized parser, that pipes the .c files through the C preprosessor, that work all of the time, but this is quite some work as well. Note however that piping every source file through the C prepropessor is VERY SLOW. That is one of the reason the winapi tools doesn't do that.

2 1

Re: wine/tools winemaker (1.49 - breaks winemaker)
by Martin Wilck 11 Sep '02

11 Sep '02

Am Mit, 2002-09-11 um 03.09 schrieb Alexandre Julliard: > ChangeSet ID: 1031706598725635746101947 Sorry, but this patch is severely broken - it introduces several regressions. > Log message: > Francois Gouget <fgouget(a)codeweavers.com> > Store the global settings in Make.rules.in instead of duplicating them > in each Makefile.in file. > Introduce generate_from_template which replaces generate_configure > and generate_generic > Simplify the wrapper generation by using generate_from_template. > Rename configure.in to configure.ac. Now works with autoconf 2.5x. This is what happened to me with a trivial winelib test setup: 1. winemaker doesn't even run - perl compilation error in generate_wrapper_file(). 2. After that's fixed, autoconf fails. Winemaker may now work with autoconf 2.5x, but is broken with 2.13. I wonder if this is intentional. If yes, I am against it - you cannot assume that all winelib developers have autoconf 2.5x. At the very least, it should be documented. 3. After that's fixed, configure fails with "Could not include the Wine headers (windef.h)". At this point I have stopped investigating further. Here is a quick fix for 1. and 2. - I will look into 3. and possible further problems later. Martin Index: winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.49 diff -u -r1.49 winemaker --- winemaker 11 Sep 2002 01:09:58 -0000 1.49 +++ winemaker 11 Sep 2002 09:52:51 -0000 @@ -1670,6 +1670,7 @@ { my $path=$_[0]; my $target=$_[1]; + my $app_name=@$target[$T_NAME]; return generate_from_template("wrapper.c","$path${app_name}_wrapper.c",[ ["APP_NAME",@$target[$T_NAME]], @@ -2069,7 +2070,7 @@ ["PROJECTS",join("\n",map { "@$_[$P_PATH]Makefile" } @projects)], ["SOURCE","$a_source_file"], ["NEEDS_MFC","$needs_mfc"]]); - system("autoconf"); + system("autoconf configure.ac > configure"); # Add execute permission to configure for whoever has the right to read it my @st=stat("configure"); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On Wed, 11 Sep 2002, Dimitrie O. Paun wrote: > [...] > > Exactly! That's where I was driving at. But this depends on getting > > stuff automatically out of .c file, because this way we can retain > > the type information, which we now lose (except for strings). Once > > we have the type information, the sky's the limit... > > Hmm, for strings the spec files currently distinguish between input > strings (str) and output strings (ptr). This cannot be extracted from > the source files... unless we start using IN/OUT macros everywhere? Or we could do as winapi_{check,extract} already supports: BOOL WINAPI WaitCommEvent( HANDLE hFile, /* [in] handle of comm port to wait for */ LPDWORD lpdwEvents, /* [out] event(s) that were detected */ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { /* ... */ } Alexandre rejected having in/out markers in the .spec files so I never continued that project... > Anyway, where it would be most useful is for Winelib > applications. So if > we can support these then it would be great. Yes. > But it wouldn't it be > easier to hack the compiler? Maybe. :-) However the compiler must be really clever to determinte whether a pointer parameter is IN, OUT or IN/OUT. Futhermore it is logically impossible for stubbed functions and for stubbed functions it would be really nice to see the parameters wouldn't it? So I guess we have to put it in the source code somewhere. See my suggestion above.

1 0

Commctrl updates
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

ChangeLog Add ImageList states (ILS_*) definitions. Index: include/commctrl.h =================================================================== RCS file: /var/cvs/wine/include/commctrl.h,v retrieving revision 1.93 diff -u -r1.93 commctrl.h --- include/commctrl.h 9 Sep 2002 19:19:50 -0000 1.93 +++ include/commctrl.h 10 Sep 2002 20:15:00 -0000 @@ -487,6 +487,11 @@ #define ILCF_MOVE (0x00000000) #define ILCF_SWAP (0x00000001) +#define ILS_NORMAL 0x0000 +#define ILS_GLOW 0x0001 +#define ILS_SHADOW 0x0002 +#define ILS_SATURATE 0x0004 +#define ILS_ALPHA 0x0008 typedef struct _IMAGEINFO {

1 0

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > +#if !LISTVIEW_DEBUG > + if (infoPtr->clrBk != CLR_NONE) > +#endif > + { > + HBRUSH hBrush = CreateSolidBrush(clrbrsh); > + FillRect(hdc, rc, hBrush); > + DeleteObject(hBrush); > + } > +} I *really* don't like these #ifs. Do we really have to have them? listview.c is already such a big file, and it's not easy to work with. Let's not make it harder... -- Dimi.

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Of course potentially all types could teoretically be used so that > > would be VERY ugly... > > In theory maybe, but in practice I think there are very few structures > where this would be a problem. Yes. None of the structures in mssip have this problem AFAICS. > So we can simply fix the alignment > explicitly in these structures, either with padding or with > __attribute__. Yes. Thinking again. You can IIRC apply __attribute__((aligned(n))) to a specific field, you doesn't need to do it per type. However the only easy way to dectect automatically where you should add it will be using something like below. > A nice thing to have would be a script that parses the headers and > generates code to dump the size of all structures and the offsets of > all their members. Then we can build that code under Windows and > Winelib and compare the results. It has been in my TODO list for quite some time. I just never got around to do it. > I'm sure it's a 10 minute hack for > you to extend winapi_check to do this <g> winapi_check can't currently parse data structures so I have to teach it that first. That will take a lot more time than 10 minutes...

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > So it seems that if we add a -malign-double to CFLAGS we can > > remove the warning in pshpack8.h since now it will hopefully > > work correctly. > > Yes. However, the -malign-double option obviously causes GCC > to produce code that in some cases does not conform to the > Linux/i386 ABI. So, if Wine were to call any standard > library routines whose ABI is affected by -malign-double > (because a parameter is a structure type which is layed > out differently), we'd have a problem here ... Arrgggghhhhhhhh!!! :-( The alternative would be to add an explict __attribute__((aligned(8))) to all types larger than 4 bytes that can be used by #pragma pack(8) aligned structures. Of course potentially all types could teoretically be used so that would be VERY ugly...

2 1

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira 10 Sep '02

10 Sep '02

Francois, I am using the last version --> Wine-20020904 (Setember) and unfortunately the problem continues. What can we to change in the file keyboard.c to solve this problem? Thank you for attention!!! Salatiel Robson Francois Gouget Para: Salatiel-Robson Oliveira <fgouget(a)free.fr> <salatiel-robson.oliveira(a)serpro.gov.br> 10/09/2002 16:49 cc: wine-devel(a)winehq.com Assunto: Re: Brazilian ABNT-2 Keyboard - DeadKeys not operates properly - On Tue, 10 Sep 2002, Salatiel-Robson Oliveira wrote: > > Hi !!! > > For start, I want to say that I'm Brazilian and my english is terrible. > Excuse me for mistakes. > > My question: > > I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, > but the "DeadKeys" doesn't operates properly. > > For example: I want that appear à ã â á , but appear `a ~a ^a ´a Dead-key support is relatively recent (2 months, maybe 3). Which version of Wine are you using? If it's more than a month old I would recommend upgrading to the latest version. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

1 0

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira 10 Sep '02

10 Sep '02

Hi !!! For start, I want to say that I'm Brazilian and my english is terrible. Excuse me for mistakes. My question: I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, but the "DeadKeys" doesn't operates properly. For example: I want that appear à ã â á , but appear `a ~a ^a ´a Do you understand? Can you help me!!! Thanks!!! (See attached file: keyboard.c) Salatiel Robson

2 1

unhandled exception does not longer raise the winedbg
by Stefan Leichter 10 Sep '02

10 Sep '02

Hello, i have posted this message to cemw before, but the message appeared only partly there (checked on google) and this mailing list might be the better place for the problem. Here is my problem: In the past when i ran Paintshop Pro 5/6 in wine a wineconsole had opened with the debugger after an unhandled exception. This is broken for me in the current release (20020904). The exception occures but the debugger does not start as you can see in the attached trace. Does anyone else have this problem or know a fix? After i have noticed the problem i rebuilt the previous release (20020804) from scratch again to be sure that this is not a problem of my installation and winedbg appears as expected. Thanks for answer Stefan PS: for the record System is SuSE Linux 7.3 wine 20020904 build from source, updated by the patch file from the tiger.informatik.hu-berlin.de mailing list

1 0

Re: patches policy
by Jeff Smith 10 Sep '02

10 Sep '02

I prefer the attaching text method, to be *sure* the patch is not mangled, but that *anyone* can read it (e.g. I may want to review a patch from a location that does not offer me gzip or whatever the compression scheme de jour is). Also, have you tried adjusting the "Screen Width" settings in "General Preferences" in Yahoo Mail? -- Jeff S >From: Andriy Palamarchuk <apa3a(a)yahoo.com> >To: dimi(a)bigfoot.com, Wine Devel <wine-devel(a)winehq.com> >Subject: Re: patches policy >Date: Mon, 9 Sep 2002 11:30:37 -0700 (PDT) > >--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > Hi all, > > > > There is something concerning submitting patches > > that bothers me > > to no end: inlining vs. attaching them. >[skipped] > >I have to attach the patches :-( because I use Yahoo >online mail client and it wraps long lines. >I also usually compress patches with size >= 20-30kb >to save everybody's bandwith. > >It is good idea to add these recommendations to the >Starter's guide, even if we are not going to enforce >them. > >Andriy, >Boston, MA _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 1

[PATCH] winemaker: fix catch() and throw() in winelib DLLs
by Martin Wilck 10 Sep '02

10 Sep '02

Patch: winemaker-wrapper.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-10 Modified files: - tools: winemaker * A wrapper binary should not be linked to any library passed with "-l". [ I am forwarding this to wine-devel because the problem may be deeper than I think, see below ]. Rationale: This fixes a delicate problem with catch() and throw() in a DLL used by a winelib application that has a wrapper app. I have written this small, hopefully self-explaining, shell script that demonstrates the problem. (Note that my previous winemaker patches are necessary otherwise there'll be other errors before this one comes into play). #! /bin/sh # throwtest.sh - test winemaker with catch()/throw() in a DLL # Change this to the location of your wine installation (DLL will also be installed there) WINEDIR=$HOME/exp # Extra winemaker options to build EXE: CORE DUMP with --wrap, fine without EXEOPTS="--wrap" # Extra winemaker options to build DLL DLLOPTS="" errexit () { echo "** Error $1 !! **" >&2 exit 1 } export PATH=$WINEDIR/bin:$PATH export LD_LIBRARY_PATH=$WINEDIR/lib:$LD_LIBRARY_PATH echo "Building library ..." >&2 mkdir -p trylib cd trylib rm -f * # BEWARE !!! cat > trylib.cpp <<EOF int do_try (void) { int ret = 0; try { throw(1); } catch (int e) { ret = e; } return ret; } EOF winemaker --dll $DLLOPTS . > winemaker.out 2>&1 || errexit "running winemaker for library" ## remove the "init DllMain" declaration winemaker generates echo "" >libtrylib.spec ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during library configure" make >make.log 2>&1 || errexit "building library" make install >>make.log 2>&1 || errexit "installing library" cd .. echo "Building program ..." >&2 mkdir -p tryexe cd tryexe rm -f * # BEWARE !!! cat > tryexe.cpp <<EOF #include <stdio.h> extern int do_try (void); void main (void) { printf ("Result: %d\n", do_try()); } EOF winemaker --cuiexe $EXEOPTS -ltrylib . > winemaker.out 2>&1 || errexit "running winemaker for program" ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during program configure" make >make.log 2>&1 || errexit "building program" echo "Running program ..." >&2 ./tryexe >run.out 2>&1 || errexit "running program" echo "** Success !! **" >&2 # EOF throwtest.sh On my system, this yields the following output: Building library ... Building program ... Running program ... throwtest.sh: line 65: 14430 Aborted (core dumped) ./tryexe >run.out 2>&1 ** Error running program !! ** The reason is that "-ltrylib" becomes part of the DLL_LINK make variable and the wrapper app is thus linked with "libtrylink.so". If my analysis is correct, this leads to a situation where the gcc-generated exception code for throw() jumps into the wrapper app rather than into the wrapped app - i.e. to nowhere. IMO it makes no sense to include any additional libraries in the link list for the wrapper app (=> patch). If this isn't done, the test runs fine. This may point to a conceptual problem with the wrapper app approach, but at least it seems to run fine with the patch below. Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.47 diff -u -r1.47 winemaker --- tools/winemaker 10 Sep 2002 00:42:43 -0000 1.47 +++ tools/winemaker 10 Sep 2002 18:21:57 -0000 @@ -1993,7 +1993,11 @@ } else { print FILEO "\t\$(LDSHARED)"; } - print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + if (@$target[$T_FLAGS] & $TF_WRAPPER) { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(WRAPPER_DLL_LINK) \$(LIBS)\n"; + } else { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + } if (@$target[$T_TYPE] ne $TT_DLL) { print FILEO "\ttest -f @$target[$T_NAME] || \$(INSTALL_SCRIPT) wineapploader @$target[$T_NAME]\n"; } @@ -3043,6 +3047,7 @@ ALLCFLAGS = $(CFLAGS) $(CEXTRA) $(OPTIONS) $(ALLFLAGS) ALLCXXFLAGS=$(CXXFLAGS) $(CXXEXTRA) $(OPTIONS) $(ALLFLAGS) ALLWRCFLAGS=$(WRCFLAGS) $(WRCEXTRA) $(OPTIONS) $(ALLFLAGS) +WRAPPER_DLL_LINK = $(LIBRARY_PATH) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid DLL_LINK = $(LIBRARY_PATH) $(LIBRARIES:%=-l%) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid LDCOMBINE = ld -r LDSHARED = @LDSHARED@ -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > On MSVC it does matter in the following example whether n is 4 or 8. > > Or 16 for that matter eventhough that gives the same result as 8. > > > > #ifdef _MSC_VER > > typedef __int64 longlong_t; > > #else > > typedef long long longlong_t; > > #endif > > > > #pragma pack(n) > > typedef struct { > > char x; > > longlong_t y; /* offset is 4 if n = 4, but is 8 if n = > 8 or n = 16*/ > > } longlong_n; > > #pragma pack() > > I would assume that MSVC and GCC use different structure > layouts even without any #pragma pack(), because the > default aligment of 8-byte data types is different. > > As I mentioned in my other mail, GCC should use the same > layout as MSVC if you compile with -malign-double. As I mention in my other mail you are absolutely correct. :-) So it seems that if we add a -malign-double to CFLAGS we can remove the warning in pshpack8.h since now it will hopefully work correctly.

2 1

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Ah, I guess I see the problem: it doesn't really have > anything to do with #pragma pack(), but with the default > alignment of the 'long long' data type itself. > > GCC uses a default alignment of 4 bytes for 'long long', > so, if MSVC uses a default alignment of 8, that would be > the problem. You seem to be correct. With this code: #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef __attribute__((aligned (8))) long long longlong_t; #endif GNU C now works the same as with MSVC. > However, I think you can get GCC on i386 to use a default > alignment of 8 for 8-byte sized types, by specifying the > compiler option -malign-double. Yes, that works with GNU C as well. Even without my hack above. > (Then you'll probably > have to use -mpreferred-stack-boundary=3 instead of > -mpreferred-stack-boundary=2 as well.) It doesn't seem to do any difference in my simple example either with -mpreferred-stack-boundary=2 or -mpreferred-stack-boundary=3. The only thing that matters is whether -malign-double is set.

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > - No GNU C compiler not even 3.1 support #pragma pack(8) nor > > does it support #pragma pack(16). It doesn't even give a warning. > > Well, GCC does support #pragma pack(8) and #pragma pack(16). > They just don't do anything on i386, because they don't need to. > > What #pragma pack(N) means is: if any structure member would > require a default alignment > N according to the normal rules, > reduce that alignment to N. > > As on i386 no structure member ever requires a default alignment > of > 8, #pragma pack(8) never needs to do anything. > > You appear to think that #pragma pack(N) should sometimes > *increase* some alignment requirement -- but it never does. That sound reasonable. However Microsoft doesn't seem to be reasonable. :-) > Under what circumstances do you think it should? Actually I don't think anything. I have tested what different compilers does. :-) As I explain in my latest mail (that perhaps you didn't read since it was only 5 minutes between the mails :-). On MSVC it does matter in the following example whether n is 4 or 8. Or 16 for that matter eventhough that gives the same result as 8. #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef long long longlong_t; #endif #pragma pack(n) typedef struct { char x; longlong_t y; /* offset is 4 if n = 4, but is 8 if n = 8 or n = 16*/ } longlong_n; #pragma pack()

2 1

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I'm totally at loss as to what to do. Not that it currently > matters since > > the data structures isn't currently used but someday > somebody will... > > Well, we need to add explicit padding in the structures to respect the > alignment that MSVC uses. That should only be required at the end of > the structures I think, so it's not too bad. Unfortunately its a little more complicated than that, it effects the internal offset of fields as well in some case. In the normal case below it doesn't matter whether n is 4 or 8. #pragma pack(n) typedef struct { char x; long y; /* offset is 4 both for n = 4 and n = 8 */ } long_n; #pragma pack() However is the case below is does matter whether n is 4 or 8: #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef long long longlong_t; #endif #pragma pack(n) typedef struct { char x; longlong_t y; /* offset is 4 if n = 4, but is 8 if n = 8 */ } longlong_n; #pragma pack() In short, if the size of a field is larger than 4 it matters internally whether alignment is 4 or 8. Now in the case of mssip.h, I can't see any fields that have sizes larger than 4 so we could easily handle that special case as you suggested. However in general we can not...

2 1

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> On Tue, 10 Sep 2002, Patrik Stridvall wrote: > > > > While compiling the latest tree, I get this: > > > > > > [dimi@dimi wine]$ make -s > > > In file included from ../../include/mssip.h:49, > > > from main.c:22: > > > ../../include/pshpack8.h:47:6: warning: #warning "8 as > > > alignment is not supported" > [...] > > It seems that gcc or at least a previous versions of GCC > > didn't support it since somebody (Alexandre?) added a > > warning in pshpack8.h. > > It may have been me. I think at the time it was only meant for gcc, > which was the only things you could compile Wine with anyway. > The specific version of gcc is 2.95, and but I'm really not sure the > situation has changed. It hasn't. GCC 3.1 has the same problem. > > Futhermore Micrsoft C/C++ (or at least later version of it) > > contrary to the claim of pshpack8.h support it so it > > wrong at the point at least AFAIK. > > Yes, Visual C++ supports alignment 8 which is the problem (so that > defined(_MSC_VER) should have been moved elsewhere, just to avoid the > warning in fact). > > How we can handle such alignment issues in Wine whn compiled with gcc > I'm not sure. Neither am I. I have tested the alignment with various compiler and got the follow result: - No GNU C compiler not even 3.1 support #pragma pack(8) nor does it support #pragma pack(16). It doesn't even give a warning. - MSVC 6.0 support #pragma pack(8) but not #pragma pack(16) - The Solaris compiler (old version) doesn't even support #pragma pack(4), but then 4 is the default so it doesn't really matter that much (except for a warning). It support #pragma pack(1) and #pragma pack(2) though. So the conclusion is that only MSVC support #pragma pack(8), nothing else. I'm totally at loss as to what to do. Not that it currently matters since the data structures isn't currently used but someday somebody will... PS. I can't understand why GNU C doesn't support it, it can't be that difficult to implement can it? Nether the less that fact that it doesn't warn about it is even worse. That certainly can't be difficult to implement.

5 4

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> While compiling the latest tree, I get this: > > [dimi@dimi wine]$ make -s > In file included from ../../include/mssip.h:49, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:80, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:88, > from main.c:22: > ./../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:97, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:109, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:123, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:140, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" Ah, yes. I forgot to investigate that issue further. Sorry. First of all I want so say that the warning in itself is harmless. However anything using data structures from the header might not work correctly, but then currently only stub functions use it so it doesn't really matter. The problem is that mssip.h needs 8 as alignement for its data structures. It seems that gcc or at least a previous versions of GCC didn't support it since somebody (Alexandre?) added a warning in pshpack8.h. Futhermore Micrsoft C/C++ (or at least later version of it) contrary to the claim of pshpack8.h support it so it wrong at the point at least AFAIK. The big question is how should the following lines look like: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif Or perhaps phrased in another way: What compiler and specifically what versions or the compiler supports and handles #pragma pack(8) correctly? Note that just because it compiles without warning (or error) doesn't mean that it supports it correctly.

2 1

patches policy
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

Hi all, There is something concerning submitting patches that bothers me to no end: inlining vs. attaching them. I don't know about others, but for me 99/1 rule applies: I at least skim over 99% of the patches inlines in the message, whereas I bother to read at most 1% of the ones attached/tar.gzed/ziped. Maybe I'm an extreme case, but there's got to be more to it than my personal quirks. If a patch is sent to wine-patches, it's sent there for peer review. If you don't want the review, send it to Alexandre directly, even though I suggest this is avoided as much as possible. However, it you do send it to wine-patches, please, *please* inline it! What about a nice patch submission policy: -- unified diff only (required) -- have a decent subject (recommended) -- a long description (optional, if the change warrants it) -- a meaningful ChangeLog entry (required) -- new files, if any, included in patch, diffed against /dev/null (required) -- patch inlined at the end of the message (required) -- one changeset per message Most of these things are already followed by most people, with the exception of the inlining bit. Alexandre, what about you reject patches that aren't in this format with a pointer to these rules? All this is a matter of habit, and I think we'll all benefit if these rules are followed. -- Dimi.

9 12

mssip.h trouble
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

While compiling the latest tree, I get this: [dimi@dimi wine]$ make -s In file included from ../../include/mssip.h:49, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:80, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:88, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:97, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:109, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:123, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:140, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" nm: devenum.dll.tmp.o: no symbols nm: dplay.dll.tmp.o: no symbols -- Dimi.

1 0

Re: winedbg: enhancing symbol lookup
by Alexandre Julliard 10 Sep '02

10 Sep '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > --- debugger/break.c 30 Jul 2002 00:06:34 -0000 1.35 > +++ debugger/break.c 2 Sep 2002 19:39:59 -0000 > @@ -421,10 +421,15 @@ > DBG_VALUE value; > int i; > > - if (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > + switch (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > { > + case TRUE: > DEBUG_AddBreakpoint(&value, NULL, TRUE); > return; > + case FALSE: > + break; > + case ABORT: /* user aborted symbol lookup */ > + return; > } Please don't invent a third boolean state. A boolean is either TRUE or FALSE; if you need more than that you should define a new enum type with meaningful names. Reusing TRUE and FALSE will cause major confusion. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winemaker: wineapploader generation
by Alexandre Julliard 10 Sep '02

10 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > * tools/winemaker > Generate wineapploader using autoconf rather than from the Makefile Actually it's better to generate this kind of file from the Makefile; this way you can change things without having to re-run configure (by passing the values directly to make). For that reason the autoconf guidelines state that configure should only generate makefiles, not other files. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: patches policy
by Patrik Stridvall 09 Sep '02

09 Sep '02

> There is something concerning submitting patches that bothers me > to no end: inlining vs. attaching them. Yes!!! Finally. Another flamewar. :-) I will mainly comment how I submit my patches. I don't personally care that much what others do. However if Alexandre finds some way more convenient I can certain change... > I don't know about others, but for me 99/1 rule applies: I at least > skim over 99% of the patches inlines in the message, whereas > I bother to read at most 1% of the ones attached/tar.gzed/ziped. > Maybe I'm an extreme case, but there's got to be more to it than > my personal quirks. > > If a patch is sent to wine-patches, it's sent there for peer review. > If you don't want the review, send it to Alexandre directly, even > though I suggest this is avoided as much as possible. However, > it you do send it to wine-patches, please, *please* inline it! > > What about a nice patch submission policy: > -- unified diff only (required) Agreed (if the file already exists). > -- have a decent subject (recommended) Agreed. > -- a long description (optional, if the change warrants it) Agreed. > -- a meaningful ChangeLog entry (required) Agreed. > -- new files, if any, included in patch, diffed against > /dev/null (required) I currently use .tar files since it handles the case that Uwe was talking about that is new directories. But then, I use a script to generate my patches, so I can make the normal case (no new directory) as a diff against /dev/null. > -- patch inlined at the end of the message (required) If it is inlined at all it should certainly be at the end, agreed. > -- one changeset per message What about dependent changesets? Or changeset that are otherwise logically dependent (even if not syntactically or semantically)? I guess they could be perhaps is multiple messages like: Subject: Fix various bugs (part 1 of 3) Subject: Fix various bugs (part 2 of 3) Subject: Fix various bugs (part 3 of 3) I currently mail all my patches from Windows (Outlook) just out of habit I guess since it is where I send my other mail so that would require manual work. However I guess I could mail them directly from my Linux box using another script...

3 2

re: RFC: 'test' bugzilla keyword
by Dan Kegel 09 Sep '02

09 Sep '02

Francois Gouget wrote: > if we make it easy to track > conformance test issues in Bugzilla, we may get new contributers (sure I > realize it's not a magic bullet either). Thus I propose to add a 'test' > keyword to make it easy to find such issues in bugzilla for people > specifically interested in conformance tests. Excellent idea. The keyword 'test' might be a bit confusing -- some bug tracking systems use that word as a state. How about something short that has very few hits on Google? Like, um, "apifail" or "unitfail"? - Dan

4 6

[PATCH] winemaker fixes
by Martin Wilck 09 Sep '02

09 Sep '02

Hi, the patch below fixes a few things in winemaker. It seems to work with my app, but needs more testing, especially for MFC apps. Modified files: tools: winemaker documentation: winemaker.man Changelog: - adapt winemaker to the new way winebuild handles imports. - fix crashes due to winemaker-generated wrapper app closing libraries (is this one correct??) - Fix some minor bugs in the wrapper.c template. - change semantics of --nomfc option such that it overrides automatic setting of --mfc if stdafx.h or stdafx.cpp are found. (this may cause problems to some people. For me the old behaviour was a pain in the neck, because VC++ generates stdafx.h always, even for pure C projects). Feedback, please ! - Add --nodlls option to suppress auto-generated import list for simple apps. - Adapt man page. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.39 diff -u -r1.39 winemaker --- tools/winemaker 14 Apr 2002 19:31:23 -0000 1.39 +++ tools/winemaker 22 May 2002 16:49:18 -0000 @@ -233,6 +233,14 @@ my $TF_MFC=4; ## +# User has specified --nomfc option for this target or globally +my $TF_NOMFC=8; + +## +# --nodlls option: Do not use standard DLL set +my $TF_NODLLS=16; + +## # Initialize a target: # - set the target type to TT_SETTINGS, i.e. no real target will # be generated. @@ -435,23 +443,37 @@ push @{@$target[$T_LIBRARY_PATH]},$option; } elsif ($option =~ /^-l/) { push @{@$target[$T_LIBRARIES]},"$'"; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--wrap/) { - @$target[$T_FLAGS]|=$TF_WRAP; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--nowrap/) { - @$target[$T_FLAGS]&=~$TF_WRAP; - } elsif ($option =~ /^--mfc/) { - @$target[$T_FLAGS]|=$TF_MFC; + } elsif ($option =~ /^--wrap/) { if (@$target[$T_TYPE] != $TT_DLL) { @$target[$T_FLAGS]|=$TF_WRAP; + } else { + print STDERR "warning: option --wrap is illegal for DLLs - ignoring"; + }; + } elsif ($option =~ /^--nowrap/) { + if (@$target[$T_TYPE] != $TT_DLL) { + @$target[$T_FLAGS]&=~$TF_WRAP; + } else { + print STDERR "warning: option --nowrap is illegal for DLLs - ignoring"; } + } elsif ($option =~ /^--mfc/) { + @$target[$T_FLAGS]|=$TF_MFC; + @$target[$T_FLAGS]&=~$TF_NOMFC; } elsif ($option =~ /^--nomfc/) { @$target[$T_FLAGS]&=~$TF_MFC; - @$target[$T_FLAGS]&=~($TF_MFC|$TF_WRAP); + @$target[$T_FLAGS]|=$TF_NOMFC; + } elsif ($option =~ /^--nodlls/) { + @$target[$T_FLAGS]|=$TF_NODLLS; } else { print STDERR "error: unknown option \"$option\"\n"; return 0; } } + if (@$target[$T_TYPE] != $TT_DLL && + @$target[$T_FLAGS] & $TF_MFC && + !(@$target[$T_FLAGS] & $TF_WRAP)) { + print STDERR "info: option --mfc requires --wrap"; + @$target[$T_FLAGS]|=$TF_WRAP; + } return 1; } @@ -541,7 +563,7 @@ } elsif ($dentry =~ /\.c$/i and $dentry !~ /\.spec\.c$/) { push @sources_c,"$dentry"; } elsif ($dentry =~ /\.(cpp|cxx)$/i) { - if ($dentry =~ /^stdafx.cpp$/i) { + if ($dentry =~ /^stdafx.cpp$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { push @sources_misc,"$dentry"; @$project_settings[$T_FLAGS]|=$TF_MFC; } else { @@ -551,7 +573,7 @@ push @sources_rc,"$dentry"; } elsif ($dentry =~ /\.(h|hxx|hpp|inl|rc2|dlg)$/i) { push @sources_misc,"$dentry"; - if ($dentry =~ /^stdafx.h$/i) { + if ($dentry =~ /^stdafx.h$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { @$project_settings[$T_FLAGS]|=$TF_MFC; } } elsif ($dentry =~ /\.dsp$/i) { @@ -774,10 +796,13 @@ push @exe_list,$target; } # This is the default link list of Visual Studio, except odbccp32 - # which we don't have in Wine. Also I add ntdll which seems - # necessary for Winelib. - my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll ntdll.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); - @$target[$T_DLLS]=\@std_dlls; + # which we don't have in Wine. + my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); + if (@$target[$T_FLAGS] & $TF_NODLLS == 0) { + @$target[$T_DLLS]=\@std_dlls; + } else { + $target[$T_DLLS]=[]; + } push @{@$project[$P_TARGETS]},$target; # Ask for target-specific options @@ -982,7 +1007,8 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "ntdll.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; my $index=bsearch(@$target[$T_SOURCES_C],"@$wrapper[$T_NAME]_wrapper.c"); @@ -1634,32 +1660,10 @@ $rcname =~ s+([^/\w])+\\$1+g; print FILEO "rsrc $rcname.res\n"; } - print FILEO "\n"; - my %dlls; - foreach $dll (@{$global_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - if (defined $project_settings) { - foreach $dll (@{@$project_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - } - foreach $dll (@{@$target[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } # Don't forget to export the 'Main' function for wrapped executables, # except for MFC ones! - if (@$target[$T_FLAGS] == $TF_WRAP) { + if ((@$target[$T_FLAGS]&($TF_WRAP|$TF_WRAPPER|$TF_MFC)) == $TF_WRAP) { if (@$target[$T_TYPE] == $TT_GUIEXE) { print FILEO "\n@ stdcall @$target[$T_INIT](long long ptr long) @$target[$T_INIT]\n"; } elsif (@$target[$T_TYPE] == $TT_CUIEXE) { @@ -1867,6 +1871,7 @@ generate_list("${canon}_LIBRARY_PATH",1,@$target[$T_LIBRARY_PATH]); generate_list("${canon}_LIBRARIES",1,@$target[$T_LIBRARIES]); generate_list("${canon}_DEPENDS",1,@$target[$T_DEPENDS]); + generate_list("${canon}_IMPORTS",1,@$target[$T_DLLS]); print FILEO "\n"; generate_list("${canon}_OBJS",1,["\$(${canon}_C_SRCS:.c=.o)","\$(${canon}_CXX_SRCS:.cpp=.o)","\$(EXTRA_OBJS)"]); print FILEO "\n\n\n"; @@ -1952,7 +1957,7 @@ print FILEO "\t-\$(STRIP) \$(STRIPFLAGS) \$\@\n"; print FILEO "\n"; print FILEO "\$(${canon}_SPEC_SRCS:.spec=.spec.c): \$(${canon}_SPEC_SRCS) \$(${canon}_SPEC_SRCS:.spec=.tmp.o) \$(${canon}_RC_SRCS:.rc=.res)\n"; - print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS)\n"; + print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS) \$(${canon}_IMPORTS:%=-l%)\n"; print FILEO "\n"; my $t_name=@$target[$T_NAME]; if (@$target[$T_TYPE]!=$TT_DLL) { @@ -2168,7 +2173,7 @@ print STDERR "Usage: winemaker [--nobanner] [--backup|--nobackup] [--nosource-fix]\n"; print STDERR " [--lower-none|--lower-all|--lower-uppercase]\n"; print STDERR " [--lower-include|--nolower-include]\n"; - print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll]\n"; + print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll|--nodlls]\n"; print STDERR " [--wrap|--nowrap] [--mfc|--nomfc]\n"; print STDERR " [-Dmacro[=defn]] [-Idir] [-Pdir] [-idll] [-Ldir] [-llibrary]\n"; print STDERR " [--interactive] [--single-target name]\n"; @@ -2181,9 +2186,6 @@ exit (2); } - -project_init(\@main_project,""); - while (@ARGV>0) { my $arg=shift @ARGV; # General options @@ -2244,11 +2246,13 @@ $opt_flags&=~$TF_WRAP; } elsif ($arg eq "--mfc") { $opt_flags|=$TF_MFC; - $opt_flags|=$TF_MFC|$TF_WRAP; $needs_mfc=1; } elsif ($arg eq "--nomfc") { - $opt_flags&=~($TF_MFC|$TF_WRAP); + $opt_flags&=~$TF_MFC; + $opt_flags|=$TF_NOMFC; $needs_mfc=0; + } elsif ($arg eq "--nodlls") { + $opt_flags|=$TF_NODLLS; # Catch errors } else { @@ -2263,6 +2267,11 @@ usage(); } } + + if ($opt_flags & $TF_MFC && $opt_target_type != $TT_DLL) { + print STDERR "info: option --mfc requires --wrap\n"; + $opt_flags |= $TF_WRAP; + }; } if (!defined $opt_work_dir) { @@ -2278,6 +2287,8 @@ print_banner(); } +project_init(\@main_project,""); + # Fix the file and directory names fix_file_and_directory_names("."); @@ -3094,6 +3105,8 @@ * This is either CUIEXE for a console based application or * GUIEXE for a regular windows application. */ +#define GUIEXE 0 +#define CUIEXE 1 #define APP_TYPE ##WINEMAKER_APP_TYPE## /** @@ -3138,11 +3151,11 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) #else -int WINAPI Main(int argc, char** argv, char** envp) +int WINAPI main(int argc, char** argv, char** envp) #endif { void* appLibrary; - HINSTANCE hApp,hMFC,hMain; + HINSTANCE hApp = 0, hMFC = 0, hMain = 0; void* appMain; char* libName; int retcode; @@ -3212,7 +3225,7 @@ } /* Get the address of the application's entry point */ - appMain=(WinMainFunc*)GetProcAddress(hMain, appInit); + appMain=GetProcAddress(hMain, appInit); if (appMain==NULL) { char format[]="Could not get the address of %s (%d)"; char* msg; @@ -3232,11 +3245,6 @@ #endif /* Cleanup and done */ - FreeLibrary(hApp); - if (hMFC!=NULL) { - FreeLibrary(hMFC); - } - dlclose(appLibrary); free(libName); return retcode; Index: documentation/winemaker.man =================================================================== RCS file: /home/wine/wine/documentation/winemaker.man,v retrieving revision 1.5 diff -u -r1.5 winemaker.man --- documentation/winemaker.man 2 Oct 2001 17:47:34 -0000 1.5 +++ documentation/winemaker.man 22 May 2002 16:49:19 -0000 @@ -17,7 +17,7 @@ ] .br [ -.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " +.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " "| " "--nodlls " ] .br [ @@ -121,6 +121,14 @@ i.e. for which it does not know whether it is an executable or a library, it should assume it is a library. .TP +.I --nodlls +This option tells winemaker not to use the standard set of winelib libraries +for imports. That is, any DLL your code uses must be explicitly passed to +winemaker with -i options. +The standard set of libraries is: advapi32.dll, comdlg32.dll, gdi32.dll, +kernel32.dll, odbc32.dll, ole32.dll, oleaut32.dll, shell32.dll, user32.dll, +winspool.drv. +.TP .I --wrap Specifies that executable targets should be built as libraries and a small executable wrapper generated for them. This technique is sometimes required @@ -137,7 +145,9 @@ generates wrappers for these targets that are executables. .TP .I --nomfc -Specifies that targets are not MFC-based. This is the default. +Specifies that targets are not MFC-based. This option disables use of MFC libraries +even if winemaker encounters files "stdafx.cpp" or "stdafx.h" that would cause it +to enable MFC automatically if neither --nomfc nor --mfc was specified. .TP .I -Dmacro[=defn] Adds the specified macro definition to the global list of macro definitions. @@ -149,8 +159,7 @@ Appends the specified directory to the global library path. .TP .I -idll -Adds the Winelib library to the global list of Winelib libraries to import -in the spec file. +Adds the Winelib library to the global list of Winelib libraries to import. .TP .I -llibrary Adds the specified library to the global list of libraries to link with.

2 5

Recent change causes bad QuickBooks behaviour(?)
by Carl Sopchak 09 Sep '02

09 Sep '02

I have been using Wine to run QuickBooks fairly successfully for several months now. However, I frequently do CVS updates because I'm also trying to run Quicken, and there are several issues that I'm hoping will get fixed this way. (I have fixed a few of them myself, and am working on one now, but my time [like everyone else's, I'm sure] is limited...) It's been a few weeks since I've run QuickBooks (8/19 was my last transaction date, so it'd be somewhere around there...). When I went to run it today (after several CVS updates on wine, including "moments ago"), after the company data file is opened, the main menu bar goes away. This was definately NOT a problem the last time I ran QuickBooks, so I surmise that it is the result of a change committed to CVS within the past two to three weeks that is causing this behaviour. It happens in both managed and unmanaged window mode. Basically, the main menu bar should be at the top of the window, but the configurable taskbar / buttonbar is displayed "over" it. The accellerator keys for the menu bar are no longer recognised (the program beeps if you try to use <alt>f [for example] to get to the File menu). I am more than willing to try to debug this. I'd really rather not go back to Windows to run QuickBooks, but I HAVE TO HAVE it (for running my company's finances!) But, before I spend days trying to find out what changed in the past few weeks, I was wondering (no, hoping, really) if anyone might recognize this problem as being a possible result of a recent CVS committed change. Well, in the mean time, I guess I'll look through the CVS commits from the past few weeks (arghhh!)... Any help would be greatly appreciated... Thanks, Carl

3 6

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> > Yes. I have submitted most of my changes of that kind to the > > CVS so the current status of that is quite good. > > What is the status of WINE under MS_VC? I ask because I dont > have a copy of MS_VC and I would like > to see if there is anything that builds right with it but not > with Mingw/Cygwin. What > dlls/programs can you build atm? The compile status in general is quite good. The link status however is not. A lot more work remains.

1 0

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> I want to get some comments about how others here try to get the DLLs > compiled > under Visual C. I went ahead and tried to do this for > shell32.dll and after > a > little work it went so far fine. However after creating a > config.h file for > Visual C with a few definitions such as for inline, I had to > make some minor > changes to some of the c source files such as adding an > #include "config.h" > and sometimes #include "wine/port.h" to the beginning. Yes. I have submitted most of my changes of that kind to the CVS so the current status of that is quite good. > Is this the recommended way of doing things or is there a reason that > "config.h" > shouldn't be included in some of the dll source files? I ask because I > noticed > that in a few of the shell32 files it is included but in the > several of them > it wasn't and in a few it doesn't (yet) need to be. Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file. cd wine ./tools/winapi/msvcmaker Then open wine.dsw in Visual Studio. PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.

2 1

Re: Trying to debug Paradise Poker client
by Per Nystrom 09 Sep '02

09 Sep '02

Ok, these are the lines that concern me when I'm running it with the builtin advapi32 dll: 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,00000000,00000001,f0000000) ret=40cc424b 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc424b 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,40d0e840 "Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=40cc429c 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc429c What can be done to fix it? Thanks, Per Nystrom

2 1

Wine DLLs compiled under Visual C
by Rolf Kalbermatter 09 Sep '02

09 Sep '02

I want to get some comments about how others here try to get the DLLs compiled under Visual C. I went ahead and tried to do this for shell32.dll and after a little work it went so far fine. However after creating a config.h file for Visual C with a few definitions such as for inline, I had to make some minor changes to some of the c source files such as adding an #include "config.h" and sometimes #include "wine/port.h" to the beginning. Is this the recommended way of doing things or is there a reason that "config.h" shouldn't be included in some of the dll source files? I ask because I noticed that in a few of the shell32 files it is included but in the several of them it wasn't and in a few it doesn't (yet) need to be. Rolf Kalbermatter

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel