January 2003 - Wine-Devel - list.winehq.org

Re: Francois's winsock.h patch

by Francois Gouget

On 3 Jan 2003, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > Are you going to apply Francois's winsock.h patch that fixes the > > Winelib problems that I encountered on wxWindows? > > My impression was that it was not ready yet. Francois? I fired up FreeBSD today and did some tests. Unfortunately it does not work very well: I get conflicts between the htonl defined via sys/types.h and in winsock.h. So I will need to rework this a bit more :-( -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Jan. 6, 2003

Re: Mac OS X/Darwin port of Wine

by Mike Hearn

Supposedly Mac OS X already has the largest installed base of any single *nix distribution and certainly is ahead of Linux on the desktop. So there are easily as many potential users of Wine for Mac OS X as Wine for X86-whatever. And Virtual PC has been popular & successful. Actually, according to figures from Apple and IDC (guess which is more neutral) desktop Linux has at least double and possibly quadruple the installed userbase of MacOS X. I have pointed this out several times when people make statements such as that, and have yet to be refuted, so be careful when saying things like MacOS is "certainly ahead of Linux", as the statistics don't back that up. *shrug* Bear in mind that to actually do a MacOS port would require rewriting quite large parts of Wine even if you still use an X server, and then Windows apps would still look like Windows apps, not Aqua apps. Please don't get discouraged, but you should be aware of how much work it involves before starting. As CPU emulation would be one of the trickier parts, I'd definately go with the advice to start by making x86 binaries work on Linux/PPC, as that keeps the number of things that could interfere to a minimum. ta -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 6, 2003

Re: CorelDraw 4 almost working

by Dimitrie O. Paun

On January 5, 2003 04:43 pm, Claudiu Costin wrote: > Hi Dimitri, It's Dimitrie dude, you should know, we speak the same mother tongue! :) > Thank's for your patch. Applied, show it's > stub, but CORELDRW.EXE crash on something strange. > Is Wine missing something simple or require lot > of work to fix? Wine is missing lots of stuff! ;) For the life of me I don't understand how you you got this files. Why are there different instance one beside the other? Anyway, don't get your hopes up -- these are complex apps, it takes a lot of effort to get them running. -- Dimi.

Jan. 6, 2003

Re: WIP RPC test code (RFC): rpc_K01-pre2.diff

by Greg Turner

On Sunday 05 January 2003 05:15 pm, Alexandre Julliard wrote: > Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > > what about an environment variable ? > > we already use something like this for the wineserver (WINESERVER), > > the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? > > I don't think we want a separate environment variable for every > single Wine program. Simply setting the correct WINEDLLPATH should be > enough (and runtest should be doing that already AFAICS). I think this is also not cross platform portable. I probably need to generate a matrix of _s.c, _c.c, and .h files for powermac/linux, sparc, ia64, er.. what was the list again? Ugh. That approach is not going to scale very gracefully... widl, once it is capable, is the easy-to-identify solution, but presumably the full infrastructure that would allow RPC stub generation would be quite an undertaking... all those nasty modes, /Oi.* business, architecture switches, and, perhaps worst of all, format-string generation... probably a barrel of snakes in there alone. I guess, the real answer, is go brush up on my bison skills... until then, I guess a matrix of files is the best I can do. I plan to implement that using the library aproach mentioned by Eric, instead of the one-big-exe approach, also mentioned by Eric, to achieve this. It's more verbose, but, it supports the needs of a multiplatform test, and is the more elegant solution w.r.t. widl in this intermediate stage: widl can very nearly generate the stringinput.h I would need for libraries, whereas with this /rename trick, I had to use MIDL's stringinput.h. I think you shouldn't comitt my K01 until I fix some of that stuff; it will probably break a lot of trees to throw it into CVS in this condition. Hopefully, I can figure out the basic make incantations, and if not, well, you will hear from me. -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 6, 2003

Re: problem building tests with msvc6

by Francois Gouget

On Sun, 5 Jan 2003, Dan Kegel wrote: [...] > Oh, you're talking about the batch file in > http://fgouget.free.fr/wine/winetests.zip Yep, that's the one. > I guess I could use that, though it'd be nice if it were > in cvs, or automatically generated. Yes, it would be nice to generate it automatically... from msvcmaker for instance... > In order to use it, > I'll have to write a script that moves all the newly built .exe's > to the top level directory. You can adapt the following script which I use to generate the winetests.zip file (but it's a very ad-hoc script): #!/bin/sh rm winetests.zip zip -j winetests.zip \ dlls/advapi32/tests/Output/Win32_MSVC_Headers/advapi32_test.exe \ dlls/dsound/tests/Output/Win32_MSVC_Headers/dsound_test.exe \ dlls/gdi/tests/Output/Win32_MSVC_Headers/gdi32_test.exe \ dlls/kernel/tests/Output/Win32_MSVC_Headers/kernel32_test.exe \ dlls/msvcrt/tests/Output/Win32_MSVC_Headers/msvcrt_test.exe \ dlls/netapi32/tests/Output/Win32_MSVC_Headers/netapi32_test.exe \ dlls/ntdll/tests/Output/Win32_Wine_Headers/ntdll_test.exe \ dlls/oleaut32/tests/Output/Win32_MSVC_Headers/oleaut32_test.exe \ dlls/rpcrt4/tests/Output/Win32_MSVC_Headers/rpcrt4_test.exe \ dlls/shell32/tests/Output/Win32_MSVC_Headers/shell32_test.exe \ dlls/shlwapi/tests/Output/Win32_MSVC_Headers/shlwapi_test.exe \ dlls/urlmon/tests/Output/Win32_MSVC_Headers/urlmon_test.exe \ dlls/user/tests/Output/Win32_MSVC_Headers/user32_test.exe \ dlls/wininet/tests/Output/Win32_MSVC_Headers/wininet_test.exe \ dlls/winmm/tests/Output/Win32_MSVC_Headers/winmm_test.exe \ dlls/winsock/tests/Output/Win32_MSVC_Headers/ws2_32_test.exe \ runtests.bat -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Jan. 6, 2003

Re: problem building tests with msvc6

by Dan Kegel

Dan Kegel wrote: > Francois Gouget wrote: >> I load winetest.dsw. This file contains one project per test with two >> configurations each, and also wineruntests. >> >> You can then select an individual project+configuration and compile it. >> When I want to recompile everything I go to Build -> Batch Build and: >> * select all 'Win32 MSVC Headers' Items >> * except for ntdll for which I select 'Win32 Wine Headers' >> * and for wineruntests which I deselect completely > > Hmm. Might be simpler to do the following: > * remove ntdll from wineruntests > * select "Win32 MSVC Headers" for wineruntests > * select "Win32 Wine Headers" for ntdll > That's less clicking... > >> Then if I want to run all the tests I use my batch script. > > What batch script is that? Is it in cvs? Oh, you're talking about the batch file in http://fgouget.free.fr/wine/winetests.zip I guess I could use that, though it'd be nice if it were in cvs, or automatically generated. In order to use it, I'll have to write a script that moves all the newly built .exe's to the top level directory. I guess I'm aiming at making it easier for Windows folks to grab the source for the tests from CVS and build them themselves under Windows. Furthermore, I'm hoping to write scripts to continuously update from cvs and run the regression tests, all on windows. (It'll be interesting making that work noninteractively.) - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 6, 2003

Re: problem building tests with msvc6

by Dan Kegel

Francois Gouget wrote: > On Sun, 5 Jan 2003, Dan Kegel wrote: > [...] > >>OK, but how do you compile all the tests then? >>wineruntests is the only project that invokes all the test subprojects. > > > I load winetest.dsw. This file contains one project per test with two > configurations each, and also wineruntests. > > You can then select an individual project+configuration and compile it. > When I want to recompile everything I go to Build -> Batch Build and: > * select all 'Win32 MSVC Headers' Items > * except for ntdll for which I select 'Win32 Wine Headers' > * and for wineruntests which I deselect completely Hmm. Might be simpler to do the following: * remove ntdll from wineruntests * select "Win32 MSVC Headers" for wineruntests * select "Win32 Wine Headers" for ntdll That's less clicking... > Then if I want to run all the tests I use my batch script. What batch script is that? Is it in cvs? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 6, 2003

Re: More On Solaris ADDRESS_SPACE_LIMIT

by Alexandre Julliard

Robert Lunnon <bob(a)yarrabee.net.au> writes: > In dlls/ntdlls/virtual.c around line 1033 in NtAllocateVirtualMemory: > > NTSTATUS res=anon_mmap_aligned( &base, size,VIRTUAL_GetUnixProt( vprot ), 0 ); > if (res) return res; > > Why is mmap used here rather than just a malloc/calloc to the OS ? If I can > convert this call to a calloc then the ADDRESS_SPACE_LIMIT test will pass on > Solaris. No, you need an mmap. What you have to do is write a routine that allocates (with mmap) all available memory above ADDRESS_SPACE_LIMIT to make sure following mmap calls can't allocate there; and that routine can then be called the first time mmap returns such an address, so that it will work for all platforms that may have that problem. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2003

Re: [RFC] __WINESRC__ & public headers

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > OK, but my problem is that we defined them on the #ifdef __WINESRC__. > Which means our code will fail with other headers (even though, granted > the fix is trivial). But I'm thinking, wouldn't it better to explicitely > define these in the files that need it? Yes that would probably be better. > Yay! Can you please suggest a solution / comment on my comments :)? > Here they are again: > > 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 This can probably be removed/commented out. > -- 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 This could be removed and replaced by explicit initializations in the files that need it. > 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 ) This one will need to be moved, and probably reworked a bit. I'll look into doing that. > -- 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 That's just an optimization, it shouldn't matter. > -- 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 > > -- 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/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 For all of these the code probably needs to be redesigned to not require API extensions. I don't know how, each one must be studied in detail. And there are probably other places where we have added Wine-specific flags without __WINESRC__ that will need to be fixed too. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2003

Re: problem building tests with msvc6

by Francois Gouget

On Sun, 5 Jan 2003, Dan Kegel wrote: [...] > OK, but how do you compile all the tests then? > wineruntests is the only project that invokes all the test subprojects. I load winetest.dsw. This file contains one project per test with two configurations each, and also wineruntests. You can then select an individual project+configuration and compile it. When I want to recompile everything I go to Build -> Batch Build and: * select all 'Win32 MSVC Headers' Items * except for ntdll for which I select 'Win32 Wine Headers' * and for wineruntests which I deselect completely Then if I want to run all the tests I use my batch script. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Jan. 6, 2003