wine-devel

wine-devel@winehq.org

5 participants
84473 discussions

Re: So lets say we do it
by Dimitrie O. Paun 31 Oct '02

31 Oct '02

On October 31, 2002 04:18 pm, Andreas Mohr wrote: > Bl**dy b*tch ! :-)) Listen man, I don't like that! I mean, what's up with the stars?!? :))) > First you annoy the h*ll out of people, and then you behave as if nothing > had ever happened and the weather was fantastic... ;-) Oh, Andy dude, you are the toughest guy on Wine-devel, crushing poor newbies without remorse. And now, all of a sudden, you become this sensible, in-touch-with-your-feelings guy?!? ;-) (ROTFL) > (BTW: the weather here is awful :) See, and you blame poor me... :P -- Dimi.

1 0

XBox
by Dirk 31 Oct '02

31 Oct '02

Could someone do something to make the need for this hardware disappear and save the world of people who love proprietrary video game consoles? There is already a tool that converts xpe files into exe. Only the bios and the improved DirectX must be re-engineered and the rest will be done by a Geforce4 (or 5) and a 2Ghz CPU.

4 3

Debugging advice
by Matthew Bloch 31 Oct '02

31 Oct '02

Hi there; I feel like I'm "nearly there" with porting this game to run with winelib, a version checked out from winehq CVS about a week ago. Because I wanted my build system to be cross-platform, and WINE only as a stop-gap, I'm using the Jam build system and so can't directly take advantage of winemaker. Plus I would rather learn and document how the build process works manually, since I can't find this information anywhere else. Anyhow I now have the 400-odd source files compiling happily against my wine header files once I'd excised the need for Direct3D. I have a directory full of object files with external references to Win32 functions and a WinMain function. So to do the final linking step I've used (based on watching the example winemine build process): $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c and then compiled & linked LSNClient.exe.c to the rest of the object files with the -shared flag, which leaves me with a shared library. Sideline: am I correct in thinking that winebuild's job is to scan the supplied object files for Win32 dependencies and construct the necessary glue code to load the needed .dll.so files? What's the reason that the linking process can't correspond more closely to "normal" linking, i.e. where I could just supply -lddraw -lwine to my program to produce a final binary? I then run ../wine/wine LSNClient.exe to try to run the game, and get this error: err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found - 16-bit dll or version conflict. err:module:PE_fixup_imports Module (file) display.dll (which is needed by Y:\Work\Nemesis\LSNClient.exe) not found Any idea what might be going wrong, or how I could diagnose it? More generally, the natively compiled .exe runs okay (if grindingly slowly, and with a couple of display glitches) under the binary loader, but I assumed that if I could produce a native version I'd be avoiding a lot of overhead and make my debugging job easier since I could use familiar GNU tools to debug my portability code as I wrote it. What efficiency gains will I make compiling a native "shared library exe" with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? I'm interested in how the latter works efficiently, so any advice in this direction would be appreciated-- I've thought on more than one occasion that maybe I should skip the WINE stop-gap and port it to SDL all at once, but the idea of being able to gradually wean the game off Win32 is appealing. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

5 6

RE: winapi_check question...
by Patrik Stridvall 31 Oct '02

31 Oct '02

> On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > Greg wrote: > > > winapi_check tells me: > > > > > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > > > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > > > documentation: \ > > > /* CLIENT_CALL_RETURN */ > > > > This is because winapi_check misparser the line: > > LONG_PTR /* CLIENT_CALL_RETURN */ > > RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING > > pFormat, va_list args) > > > > Ignore it. > > OK. You promise it won't screw up the actual documentation bot? Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-) But seriously, I wouldn't worry about it. Anyway. A real fix to the code you be nice. Presumable the type CLIENT_CALL_RETURN haven't been declared properly. > > > how shall I deal with these? > > > > Fix them as above or do as everybody elses do wait for me to fix it. > > :-) > > heh. Well, maybe I can set an example for those deadbeats :) :-)

2 1

Re: dlls/msvcrt/tests: printf
by Jaco Greeff 31 Oct '02

31 Oct '02

On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Jaco> ... Tests that will fail > Jaco> with current implementation are temporarily commented out > > Don't comment them out, matrk them "todo". Look at the syntax in > documentation/testing. I've marked the code with a "FIXME". I don't want the test sequence to fail for this issue which is solved by my msvcrt patch. The way I've done it allows others to verify the new vfprintf patch with minimal work. > And plain inlined patches are preferred against attachments. I'm doing this via a mail web interface, it has the ugly habit of doing line-wraps. I also prefer inline patches (like to see what is going on without have to save etc.), it is just not entirely possible for me at this point. *sigh* Greetings, Jaco

3 2

Some other problems ...
by Paul Millar 31 Oct '02

31 Oct '02

Hi everyone, Just a couple of problems I've noticed. They look like they're due to some broken build dependencies. 1. I have a copy of wine on my laptop which I do "cvs update" every few days. After updating today, I did the usual "./configure --enable-opengl && make depend && make" and left it to compile. But, when I tried the result, I got a client/server mismatch for SERVER_PROTOCOL_VERSION. One was claimed to be v88 whilst the other was v89. Doing a "make distclean" then repeating the build "fixed" the problem. Patch http://cvs.winehq.com/patch.py?id=6064 (committed last Tuesday) bumped the SERVER_PROTOCOL_VERSION up to 89. So it looks like some of the binaries weren't updated during the build. I tried altering the version (manually) and rebuilding, but wine rebuilt correctly. 2. WRT hit a problem last night where "make test" failed. The log included messages like: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o registry.o registry.c LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o advapi32_test.exe.spec.c -exe advapi32_test.exe -mcui registry.o testlist.o -L../../../dlls -ladvapi32 -lkernel32 -lntdll gcc -shared -Wl,-Bsymbolic advapi32_test.exe.spec.o registry.o testlist.o -o advapi32_test.exe.so -L../../../library -lwine -lm advapi32_test.exe.spec.o: In function `__wine_exe_main': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/advapi32_test.exe.spec.c:116: undefined reference to `main' registry.o: In function `test_enum_value': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_set_ok_location' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_ok' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:78: undefined reference to `winetest_set_ok_location' [... etc ...] The later build had six tests that succeded. These were the new scanf tests introduced into that build by patch http://cvs.winehq.com/patch.py?id=6107 I've just done a "make distclean" followed by a normal rebuild and test. Its currently running through the regression tests, but so far it seems to be working. These are vague reports of unrepeatable problems ... never a good thing! I'm quite busy right now (real work and everything), so I don't have time to investigate this myself. Just posting this hoping the cause its obvious to someone else :^) ---- Paul Millar

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff 31 Oct '02

31 Oct '02

On Thu Oct 31 20:04:30 2002, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > > Jaco> ... Tests that will fail > > Jaco> with current implementation are temporarily commented out > > > > Don't comment them out, matrk them "todo". Look at the syntax in > > documentation/testing. > > I've marked the code with a "FIXME". Sorry, I misunderstood the first time around, will something like todo("linux") { do(something() == 1, "whatever"); } do the trick? But unsure about the definition I should use, I can see "cygwin", "freebsd", etc. This one will fail on all non-Windows platforms. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff 31 Oct '02

31 Oct '02

On Thu, 31 Oct 2002 11:04:48 -0600, Greg Turner <gmturner007(a)ameritech.net> wrote : > On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > > - Tests that will fail with current implementation are temporarily > > commented out > > Is there a middle ground for tests that are expected to fail? If not, > IMO maybe there should be: It kinda defeats the purpose of a test > framework if we just comment out tests that don't work... Agreed. It will pass shortly though :) At this point the test will help anybody wishing to verify my latest msvcrt patch. Plus, it really should pass. The part that does fail is on Unicode printing, which give me one of a few choices: 1. Don't send in a test; 2. Be stubborn and let the test fail for everybody doing a make test; 3. Send in a really crippled test case; 4. Combination of 3 + 4 so people can easily have the framework to test if progress have been made. That is the reason why I've commented it out, hopefully shortly it will be fully featured. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Greg Turner 31 Oct '02

31 Oct '02

On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > - Tests that will fail with current implementation are temporarily > commented out Is there a middle ground for tests that are expected to fail? If not, IMO maybe there should be: It kinda defeats the purpose of a test framework if we just comment out tests that don't work... but OTOH, its pretty unfair to the other tests to have the whole "make test" fail because of some known issue. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: rpc_H_PL9
by Michael Stefaniuc 31 Oct '02

31 Oct '02

On Thu, Oct 31, 2002 at 08:49:18AM -0600, Greg Turner wrote: > LICENSE: X11 > > CHANGELOG: > * dlls/rpcrt4: rpc_server.c; > include: rpcdcep.h: > Greg Turner <gmturner007(a)ameritech.net> > - One more fixup for winapi_check > -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. 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 2

Jump to page:

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