- Wine-Devel - list.winehq.org

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

Re: console handling
by Dimitrie O. Paun Jan. 6, 2003

Jan. 6, 2003

On January 4, 2003 04:32 pm, Eric Pouech wrote: > this patch fixes a couple of issues in the console handling (but > shouldn't help Lionel & Sylvain with the issues they reported on wd) Hi Eric, Do you have any plans to reorganize wineconsole a bit so that you don't need allocate a bitmap as big as the entire buffer, but rather one as big as the displayed screen only? This way we can have 3000-5000 line scroll buffers (as I have in my konsole, rxvt, xterm, etc.) -- Dimi.

2 10