November 2002 - Wine-Devel - list.winehq.org

DPMI_CallRMProc trouble

by György 'Nog' Jeney

I realy need help with this. Whenever I call a DOSDEV_ function then that function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc. Now that function call DOSMEM_GetBlock( 64, (UINT16 *)&(context->SegSs) ) to try and allocate a stack. This fails for some reason but I dont understand why because it succeds if called from int21/48. Anyone know whats going on? nog.

Nov. 30, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On November 29, 2002 06:10 pm, Rolf Kalbermatter wrote: > But what the heck do the errors about AW functions calling Unicode > mean? Isn't that the actual idea about the AW functions? Good catch. I've updated the list, there were 52 AW functions, which leaves us 142 cross calls to deal with... :) -- Dimi.

Nov. 30, 2002

Re: Yet another D3D patch....

by Lionel Ulmer

> This patch breaks the TWIST demo that was working fine. > I think the changes in d3ddevice_create are responsible of that. Strange, it works fine here.. A bit slow when statistics are displayed (due to the locking of the D3DEVICE surface and thus needing a slow GL call like glReadPixels / glDrawPixels) but as fast as before when disabling them. But well, my tree has patches up to number 13 so maybe I broke something that was fixed later on (although I wonder what). Do you have more precise debug output ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Re: Yet another D3D patch....

by Christian Costa

Lionel Ulmer wrote: >Hi all, > >This patch should not be dependant of any others... But to prevent line >number errors, better to commit it after the 5 -> 9 series (yeah, the >attachements are numbered to ease tracking :-) ). > >Changelog: > - start of support for device locking / unlocking via glReadPixels / > glDrawPixels interface (slow but should be enough for a start) > - implement one vertex case for the D3D3/7 DrawPrimitive functions > - fix a missing \n in a TRACE call > > Lionel > This patch breaks the TWIST demo that was working fine. I think the changes in d3ddevice_create are responsible of that.

Nov. 30, 2002

MIDI Mapper fix

by Jeff Smith

I'm so happy, I just had to share it with everyone :-D Changelog: Fix for MIDI Mapper. Notes: Finally found it! This was the last thing keeping sound from working in Auralia. With just this simple patch, it now works. Auralia still has a few problems, but they are minor in comparison. It *is* kind of important for sound to work in an ear training program ;-) BTW, Thanks to Eric P. for his help getting me off to a running start with his fixes to the OSS MIDI driver a couple of weeks back. (patch is attached - Hotmail has not been kind to my inlined patches the past few days) _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

Nov. 30, 2002

Where to use dosdev

by György 'Nog' Jeney

In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.

Nov. 30, 2002

Re: Texture problems under Wine - more info

by Lionel Ulmer

> So, the question is "What is the difference between the WineX OpenGL > library and the Wine OpenGL library?" Well, for me, the only possible difference would be that : '> This begs the question: > Does the Linux implementation of pthread really work anyway? Works in WineX (though we needed some more hacks in it to make it interact well with the nvidia opengl drivers), and it'd surprise me if it doesn't still work in Wine, as the OpenGL deployed by most linux distros wouldn't work *at all* under Wine if it didn't, and people currently seem to be working on Wine as if it did work.' (copy pasted from one of Ove's mail). Because well, I did not look at WineX's OpenGL code but I doubt that it could be vastly different from Wine's one (you cannot write thunks a lot of different ways :-) ) so the only possible difference would be a bug in the pthread 'emulation' that would somehow break the drivers. By the way, what drivers are you using ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Re: valgrind and wine

by Lionel Ulmer

> ==6476== Valgrind detected that your program requires > ==6476== the following unimplemented functionality: > ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. > ==6476== This may be because the functionality is hard to implement, > ==6476== or because no reasonable program would behave this way, > ==6476== or because nobody has yet needed it. In any case, let me know > ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Which version of Valgrind is this ? According to the web page, 1.1.0 should support this system call : 'Specifically, valgrind can now deal with x86 segment registers, segment override prefixes and the modify_ldt system call'. But well, for it to really be useful, we would need then also to override in Valgrind (or in Wine) all the Threading and Heap functions. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2002

Adding support for xxx_test.exe all

by Francois Gouget

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Nov. 30, 2002

Texture problems under Wine - more info

by David D. Hagood

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

Nov. 30, 2002