- Wine-Devel - list.winehq.org

A humble request for help
by Stefan Görling Jan. 7, 2003

Jan. 7, 2003

Hi Everyone, I'm currently working on a thesis investigating how Open Source is affected by the influence of money and the interests of commercial companies. As the WINE efforts is the foundation of companies such as Codeweavers, Transgaming and Lindows, it is interesting to study how their entrance to the scene have affected the community. The thesis as well as research papers surrounding it will be released under the GNU Free Documentation License and as soon as the first drafts are available they will be published so that the community may comment upon it. In order to improve the research, it would be great if you guys could spend a few minutes on this one. I have included below a list of the most active persons on this mailinglist during the year 2002. I have tried to establish their employer as far as e-mail adresses and google could help me out, but there are lots of unknowns, and probably some errors too. So please, send me patches. Also, if you belive that there are others who should be on this list, I've only got one person from Transgaming so far, don't they contribute or are they simply silent on the mailinglist? If there are someone out there who would be willing to answer some more detailed questions, such as how long they've been doing Open Source development as a source of income and how they think it have affected them and their efforts, please drop me a line. I'd be forever greatful. The hall of fame: Dimitrie O. Paun,Unknown / Self-financed Alexandre Julliard,Codeweavers Francois Gouget,Codeweavers Eric Pouech,Unknown / Self-financed Andreas Mohr,Codeweavers Sylvain Petreolle,Unknown / Self-financed Andriy Palamarchuk,Unknown / Self-financed Steven Edwards,Unknown / Self-financed Martin Wilck,Unknown / Self-financed Patrik Stridvall,Unknown / Self-financed Uwe Bonnes,Unknown / Self-financed Dmitry Timoshkov,Codeweavers Greg Turner,Unknown / Self-financed Shachar Shemesh,Unknown / Self-financed Dustin Navea,Unknown / Self-financed Tony Lambregts,Unknown / Self-financed Ove Kaaven,Transgaming Bill Medland,ACCPAC Michael Cardenas,Lindows Lionel Ulmer,Unknown / Self-financed Duane Clark,Unknown / Self-financed Vincent Beron,Unknown / Self-financed Marcus Meissner,SUSE Brett Glass,Unknown / Self-financed Lawson Whitney,Unknown / Self-financed Dan Kegel,Unknown / Self-financed Michael Stefaniuc,RedHat

5 5

Re: dlls/Makefile.in
by Jeff Smith Jan. 7, 2003

Jan. 7, 2003

>From: Marcus Meissner <mm(a)lst.de> > > >And I don't see a reason for this change, these entries are > > >generated by a script and who should care if they are longer or not? > > What script? > >dlls/make_dlls I did not see the line at the top of dlls/Makefile.in. Oh well, nevermind then. -- Jeff S _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

[RFC] __WINESRC__ & public headers
by Dimitrie O. Paun Jan. 7, 2003

Jan. 7, 2003

Folks, With the current efforts to cleanup our headers on __WINESRC__s, I realized we are actually quite close to 'clean' header, something that should allow us to compile Wine with other headers, such as those from the w32api package that's part of mingw. This is a worthy goal as the compiler will flag problems in our headers (by complaining about different prototypes), as well as in the w32api headers. A win-win situation for the free software world. What do we need to do before we can try this stunt? Well, we need to cleanup our headers of __WINESRC__ tests that modifies them in a incompatible way. Let me be more explicit: 1. Tests that do not allow a file to be included in Wine are OK. If we use other headers, those file will simply be ignored, as they would not be used by Wine. 2. Tests to keep certain things undefined/undeclared in Wine are OK. Such tests simply make the header files a subset of the standard one, and the stuff that's not defined is not used, so all is good. 3. Tests that _add_ stuff to headers are BAD. It's clear that such things will not be present in other headers, and things will not work out as nicely. 4. Tests that modify the behavior of the headers are BAD. Same explanation as above. I will list below things that fall under 3, and 4. Ideas on how to deal with them are highly appreciated. -- It seems to me we want to move these to a wine/multimedia.h header. include/mmddk.h:#ifdef __WINESRC__ include/mmddk.h-#define DRV_QUERYDSOUNDIFACE (DRV_RESERVED + 10) include/mmddk.h-#endif include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-/* this call (GetDriverFlags) is not documented, nor the flags returned. include/mmsystem.h- * here are Wine only definitions include/mmsystem.h- */ include/mmsystem.h-#define WINE_GDF_EXIST 0x80000000 include/mmsystem.h-#define WINE_GDF_16BIT 0x10000000 include/mmsystem.h-#endif include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-#define WAVE_DIRECTSOUND 0x0080 include/mmsystem.h-#endif -- Why do we need this undef? include/objidl.h:#ifdef __WINESRC__ include/objidl.h-#undef GetObject include/objidl.h-#endif -- ? include/rpcproxy.h:#if defined(__WINESRC__) && defined(__WINE_WINE_OBJ_OLEAUT_H) include/rpcproxy.h-/* see http://msdn.microsoft.com/library/en-us/dnmsj99/html/com0199.asp?frame=true */ include/rpcproxy.h- include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateProxyFromTypeInfo( LPTYPEINFO pTypeInfo, LPUNKNOWN pUnkOuter, REFIID riid, include/rpcproxy.h- LPRPCPROXYBUFFER *ppProxy, LPVOID *ppv ); include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateStubFromTypeInfo( LPTYPEINFO pTypeInfo, REFIID riid, LPUNKNOWN pUnkServer, include/rpcproxy.h- LPRPCSTUBBUFFER *ppStub ); include/rpcproxy.h- include/rpcproxy.h-#endif -- Seems like it wants moving to a wine/base.h include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define CRITICAL_SECTION_INIT(name) { (void *)(__FILE__ ": " name), -1, 0, 0, 0, 0 } include/winbase.h-#endif -- Why are these Wine specific? include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) include/winbase.h-#endif -- This one's a bugger. It make no sense to define these things conditionally on the -- version of the compiler. One's code is written one way or another. -- I suggest we remove these completely, and we defined the NONAMELESS* explicitly -- in the files that need them. include/winnt.h:#ifdef __WINESRC__ include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# define NONAMELESSUNION include/winnt.h-#else include/winnt.h-/* Anonymous struct support starts with gcc 2.96 or gcc/g++ 3.x */ include/winnt.h-# if !defined(NONAMELESSSTRUCT) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && (defined(__cplusplu s) || (__GNUC_MINOR__ < 96))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# endif include/winnt.h-/* Anonymous unions support starts with gcc 2.96/g++ 2.95 */ include/winnt.h-# if !defined(NONAMELESSUNION) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && ((__GNUC_MINOR__ < 9 5) || ((__GNUC_MINOR__ == 95) && !defined(__cplusplus)))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSUNION -- These want moving to a wine-private header (wine/base.h?) include/winnt.h:#ifdef __WINESRC__ include/winnt.h-#define MEM_SYSTEM 0x80000000 include/winnt.h-#endif include/winnt.h:#ifdef __WINESRC__ include/winnt.h- include/winnt.h-/* Macros to retrieve the current context */ include/winnt.h- include/winnt.h-#ifdef __i386__ include/winnt.h- include/winnt.h-#define _DEFINE_REGS_ENTRYPOINT( name, fn, args ) \ include/winnt.h- __ASM_GLOBAL_FUNC( name, \ include/winnt.h- "call " __ASM_NAME("__wine_call_from_32_regs") "\n\t" \ include/winnt.h- ".long " __ASM_NAME(#fn) "\n\t" \ include/winnt.h- ".byte " #args ", " #args ) include/winsock.h:#ifdef __WINESRC__ include/winsock.h-#define FD_WINE_LISTENING 0x10000000 include/winsock.h-#define FD_WINE_NONBLOCKING 0x20000000 include/winsock.h-#define FD_WINE_CONNECTED 0x40000000 include/winsock.h-#define FD_WINE_RAW 0x80000000 include/winsock.h-#define FD_WINE_INTERNAL 0xFFFF0000 include/winsock.h-#endif -- What about these? include/wownt32.h:#ifdef __WINESRC__ include/wownt32.h-/* under Wine use the kernel functions directly so we don't have to import wow32 */ include/wownt32.h-HANDLE WINAPI K32WOWHandle32(WORD,WOW_HANDLE_TYPE); include/wownt32.h-WORD WINAPI K32WOWHandle16(HANDLE,WOW_HANDLE_TYPE); include/wownt32.h-#define WOWHandle32 K32WOWHandle32 include/wownt32.h-#define WOWHandle16 K32WOWHandle16 include/wownt32.h-#endif -- There are also some in include/winternl.h, but those can wait for now :) -- Dimi.

4 8

Re: dlls/Makefile.in
by Jeff Smith Jan. 7, 2003

Jan. 7, 2003

>From: Marcus Meissner <marcus(a)jet.franken.de> > >Some not so compatible versions of make only like this variable >in pattern replacement rules, so this might not work on all >platforms. > I tried looking into this before submitting the patch, but did not come up with anything. Do you know of any *specific* cases? >And I don't see a reason for this change, these entries are >generated by a script and who should care if they are longer or not? > What script? >Ciao, Marcus -- Jeff S _________________________________________________________________ MSN 8: advanced junk mail protection and 2 months FREE*. http://join.msn.com/?page=features/junkmail

2 1

ole:_copy_arg TKIND_INTERFACE unhandled
by Uwe Bonnes Jan. 7, 2003

Jan. 7, 2003

Hallo, it seems that the Altera Quartus installation of quartusii_22_web_edition.exe using IKernel doesn't work because of an unhandled interface: trace:ole:ITypeInfo_fnGetRefTypeInfo (0x4428f470) hreftype 0x0001 loaded SUCCESS (0x4428bda0) trace:ole:ITypeInfo_fnGetTypeAttr (0x4428bda0) fixme:ole:_copy_arg TKIND_INTERFACE unhandled. trace:ole:ITypeInfo_fnRelease (0x4428f470)->(1) trace:ole:VariantCopy (0x4443c020, 0x4443df18), vt=9 trace:ole:VariantClear (0x4443c020) the full --debugmsg +ole log is about 40 MByte and I can make it available on request. The unhandled interface happens at about 84% of the log. The installation files from Altera (about 120 MByte) can be downloaded after registration for free from http://www.altera.com/products/software/pld/products/quartus2/sof-quarwebma… I would be please if tthe installation could be made working. 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

Agent crashes and burns
by Oliver Sampson Jan. 7, 2003

Jan. 7, 2003

Howdy, It's been a little while since I've updated my CVS and I wanted to get the latest update before breaking things myself. I updated to today's CVS, and Agent would barely load and then crash. I would then get a message from the console saying it couldn't start the debugger (I've since fixed that.) So, in a panic to get my email back (so I'll be able to write this email), I went back a week in the cvs, did a new build and everything is working fine again. So, the bad news is that something since 20021228 has broken things for agent pretty severely. The worse news is that I don't have a traceback. If no one is seeing a simlar prolbem, I could download the latest CVS and try again... One other thing: As I look through the code, and I see how the procedure headers are turned into the auto doc for the web site. Would it be acceptable to refine some of those headers to include comments and return codes and so forth (like WinExec)? And if I find errors in the documentation, is the right thing to do to send a diff for the sgml? Thanks, ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

2 1

Re: dlls/Makefile.in
by Marcus Meissner Jan. 7, 2003

Jan. 7, 2003

On Mon, Jan 06, 2003 at 01:55:26PM -0600, Jeff Smith wrote: > Changelog: > Make use of the automatic variable "$<" in dll make rules. > advapi32.dll$(DLLEXT): advapi32/advapi32.dll$(DLLEXT) >- $(RM) $@ && $(LN_S) advapi32/advapi32.dll$(DLLEXT) $@ >+ $(RM) $@ && $(LN_S) $< $@ Some not so compatible versions of make only like this variable in pattern replacement rules, so this might not work on all platforms. And I don't see a reason for this change, these entries are generated by a script and who should care if they are longer or not? Ciao, Marcus

1 0

Windows XP conformance test update 1/5
by David Miller Jan. 7, 2003

Jan. 7, 2003

Not much to report this time but there is something... strange. kernel32/drive reported the following. C:\winetests>kernel32_test.exe drive drive.c:113: Test failed: GetDiskFreeSpaceA(Z:\): ret=0 GetLastError=53 drive.c:165: Test failed: GetDiskFreeSpaceW(Z): ret=0 GetLastError=53 drive: 156 tests executed, 0 marked as todo, 2 failures. Previously this test passed, so I rebooted to see if the problem went away. After reboot the kernel32 test clamed not to be a valid win32 application. Turns out the size was 0 bytes. I re-extracted the zip file and ran kernel32/drive again. This time is passed. I have not seen the failure before but I did run into the "not a valid win32 application" message before, and the file size was 0 bytes. Normally I would suspect a virus to produce that sort of problem, but I've only seen this happen to the kernel32_test.exe file. I will attempt to find out if it can be reproduced and how. I have an XP laptop as well so I'll try to verify it is not a system specific problem. oleaut32/safearray reports 8 failures but the page only shows 4 failures. C:\winetests>oleaut32_test.exe safearray safearray.c:137: Test failed: SAC(20,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(20,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:137: Test failed: SAC(21,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(21,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray: 958 tests executed, 0 marked as todo, 8 failures. Also I don't see urlmon/generated on the status page at all. It passed. C:\winetests>urlmon_test.exe generated generated: 4 tests executed, 0 marked as todo, 0 failures.

4 3

Re: Window menu
by Tony Lambregts Jan. 7, 2003

Jan. 7, 2003

Duane Clark wrote: > I've been using this patch for about a year and a half now, so I might > as well just submit it. > > Changelog: > A window with a WS_EX_APPWINDOW extended style can also > get a menu. > It's about time then.<g> I have been using it since you sent it to me. Works great! -- Tony Lambregts

1 0

RDP client under Wine?
by Hetz Ben Hamo Jan. 7, 2003

Jan. 7, 2003

Hi, A friend of mine needs to connect to MS Terminal server through his linux machines. There seems to be 3 options: 1. rdesktop - it runs, but only 8 bit colors and it's pretty slow (on 10MBit LAN) 2. WinConnect for Linux - costs a fortune - $79. 3. MS RDP client through wine - it runs up to the point where you actually connect, and then it dies.. Regarding option 3 - anyone managed to make it run somehow? any tips would be welcome... Thanks, Hetz

4 5