June 2005 - Wine-Devel - list.winehq.org

OLEAUT32/tests/vartype.c: VarDateFromStr() failure
by Saulius Krasuckas June 13, 2005

June 13, 2005

The conversion fails with some strings on WinME. MSVC debugger throws a message box saying: | Unhandled exception in oleaut32_test.exe (OLEAUT32.DLL): | 0xC0000005: Access violation How should I fix this? The only thing now I can think of is to remove "noisy" tests. Other suggestions? ChangeLog: Saulius Krasuckas <saulius.krasuckas(a)ieee.org> Remove VarDateFromStr() calls that generate exceptions on WinME. Index: dlls/oleaut32/tests/vartype.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/tests/vartype.c,v retrieving revision 1.23 diff -w -p -u -r1.23 vartype.c --- dlls/oleaut32/tests/vartype.c 6 Jun 2005 19:50:37 -0000 1.23 +++ dlls/oleaut32/tests/vartype.c 13 Jun 2005 12:28:27 -0000 @@ -3275,9 +3275,7 @@ static const char *BadDateStrings[] = "1.2.3 4.5 6", "1.2.3 4 5.6", "1.2 3.4.5.6", "1.2 3.4.5 6", "1.2 3.4 5.6", "1.2 3.4 5 6", "1.2 3 4.5.6", "1.2 3 4.5 6", "1.2 3 4 5.6", "1.2 3 4 5 6", "1 2.3.4.5.6", "1 2.3.4.5 6", "1 2.3.4 5.6", "1 2.3.4 5 6", "1 2.3 4.5.6", - "1 2.3 4.5 6", "1 2.3 4 5.6", "1 2.3 4 5 6", "1 2 3.4.5.6", "1 2 3.4.5 6", "1 2 3.4 5.6", "1 2 3.4 5 6", "1 2 3 4.5 6", "1 2 3 4 5.6", "1 2 3 4 5 6", - "1.2.3 4 am 5 6", "1.2.3 4 5 am 6", "1.2.3 4 5 6 am", "1 am 2 3 4.5.6", "1 2 am 3 4.5.6", "1 2 3 am 4.5.6" }; @@ -3382,7 +3380,6 @@ static void test_VarDateFromStr(void) /* 5 elements - interpreted as 2 & 3 digit date/times */ DFS("1.2.3 4 5"); MKRELDATE(5,4); relative += 0.04309027778; EXPECT_DBL(relative); DFS("1.2 3 4 5"); EXPECT_DBL(38415.04305555556); - DFS("1 2 3.4.5"); MKRELDATE(2,1); relative += 0.12783564815; EXPECT_DBL(relative); DFS("1 2 3 4.5"); EXPECT_DBL(37623.17013888889); /* 6 elements - interpreted as 3 digit date/times */ DFS("1.2.3 4 5 6"); EXPECT_DBL(38812.04309027778);

1 0

Re: [WINED3D] stateblocks samplers swapchains
by Marcus Meissner June 12, 2005

June 12, 2005

On Mon, Jun 13, 2005 at 01:45:02AM +0100, Oliver Stieber wrote: I do not think this even compiled for you, there are CVS merge conflicts in the patch, see below... Can you _please_ work in getting patches into WINE? If possible small and self contained. This would help all of us. :/ Ciao, Marcus .... @@ -412,17 +571,24 @@ while (pow2Width < Width) pow2Width <<= 1; while (pow2Height < Height) pow2Height <<= 1; +<<<<<<< device.c + /* TODO: support for non-power 2 textures */ + if((pow2Width > Width || pow2Height > Height) && !Usage & D3DUSAGE_RENDERTARGET){ + /** TODO: add support for non power two compressed textures (OpenGL provices support for * non-power-two textures gratis) **/ + FIXME("Non-power 2 textures are not supported\n"); +======= if(pow2Width > Width || pow2Height > Height){ FIXME("non-power-two textures unsupported\n"); /* OpenGL provides support for these gratis */ +>>>>>>> 1.31 return D3DERR_NOTAVAILABLE; } ...... - HDC hDc; + IWineD3DDevice** ppReturnedDeviceInterface, IUnknown *parent, + D3DCB_CREATEADDITIONALSWAPCHAIN D3DCB_CreateAdditionalSwapChain) { IWineD3DDeviceImpl *object = NULL; IWineD3DImpl *This = (IWineD3DImpl *)iface; +<<<<<<< directx.c + IWineD3DSwapChainImpl *swapchain; +======= int num; XVisualInfo template; HRESULT res; +>>>>>>> 1.31 ...... +<<<<<<< directx.c + /* Initialize the current view state */ + object->modelview_valid = 1; + object->proj_valid = 0; + object->view_ident = 1; + object->last_was_rhw = 0; + glGetIntegerv(GL_MAX_LIGHTS, &object->maxConcurrentLights); + TRACE("(%p,%d) All defaults now set up, leaving CreateDevice with %p\n", This, Adapter, object); +======= /* Change the display settings */ memset(&devmode, 0, sizeof(DEVMODEW)); devmode.dmFields = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT; @@ -1709,67 +1743,14 @@ IDirect3DSurface8Impl_AddRef((LPDIRECT3DSURFACE8) object->stencilBufferTarget); } */ +>>>>>>> 1.31 - /* Set up some starting GL setup */ - ENTER_GL(); + /* Clear the screen */ + IWineD3DDevice_Clear((IWineD3DDevice *) object, 0, NULL, D3DCLEAR_STENCIL|D3DCLEAR_ZBUFFER|D3DCLEAR_TARGET, 0x00, 1.0, 0);

1 0

Re: alsa: device name
by Jeremy White June 12, 2005

June 12, 2005

Kevin, I don't think this is correct. Our job is to enumerate devices available to Wine; the 'default' device is generally card #0, device #0 on that card. A system may well have multiple card and multiple devices within a card; by setting this to 'default', you have prevented a meaningful scan. I've actually got a fairly large patch coming which reorganizes Alsa device discovery to be more correct, imho. (I iterate through the cards, and iterate through device on cards; I detect and mark as the wine default the default card identified by Alsa config; I respect ALSA card/device environment variables, and, finally, I allow for explict device name override within Wine). I'm stymied currently by the fact that my patch correctly identifies a greater range of devices reported by Alsa, but then, at least with my laptop's sound card, one of the devices reported doesn't work for beans. I'm trying to figure a way to detect that card 0, device 4 doesn't work for beans so I can strip it from the results; once I finish that (if I can), I'll submit the larger patch. Cheers, Jeremy Kevin Koltzau wrote: > With ALSA 1.0, the device name "default" should be used. > "default" is mapped to plug:hw by default, but allows remapping from your alsa config > > > ------------------------------------------------------------------------ > > Index: dlls/winmm/winealsa/audio.c > =================================================================== > RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v > retrieving revision 1.85 > diff -u -d -r1.85 audio.c > --- dlls/winmm/winealsa/audio.c 9 Jun 2005 09:49:31 -0000 1.85 > +++ dlls/winmm/winealsa/audio.c 13 Jun 2005 00:47:09 -0000 > @@ -714,7 +714,7 @@ > /****************************************************************** > * ALSA_GetDeviceFromReg > * > - * Returns either "plug:hw" or reads the registry so the user can > + * Returns either "default" or reads the registry so the user can > * override the playback/record device used. > */ > static char *ALSA_GetDeviceFromReg(const char *value) > @@ -741,7 +741,7 @@ > > end: > if (!result) > - result = ALSA_strdup("plug:hw"); > + result = ALSA_strdup("default"); > > if (key) > RegCloseKey(key);

2 1

Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-02b.diff]
by Dimi Paun June 12, 2005

June 12, 2005

From: "Gerold J. Wucherpfennig" <gjwucherpfennig(a)gmx.net> Cool stuff Gerold. A few nits: > + if(PFCI_INT(hfci)->fNextCab==TRUE) { It's better to avoid explicit comparison with TRUE. What if fNextCab is 10, not 1? It's still true, but it will fail the above test. Just do: + if(PFCI_INT(hfci)->fNextCab) { Also, I know you're modifying existing code, but if it's not too much to ask, 2-space indent is hard to read, and the vast majority of developers do prefer 4-space indent. So if you don't mind, and we can find a solution, would be great if we can stick to 4-spaces instead. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

7 11

Re: Bug#313266: Please switch away from c2man (to e.g. doxygen)
by Scott Ritchie June 12, 2005

June 12, 2005

This sounds like a good summer project for me to tackle while I'm redoing the rest of the documentation. Phasing out c2man has been a long time coming. -Scott Ritchie On Sun, 2005-06-12 at 21:09 +0100, Martin Michlmayr wrote: > Package: wine > Version: 0.0.20050419-1 > Severity: wishlist > > Please switch away from c2man and use something else, for example doxygen. > > In http://lists.debian.org/debian-release/2003/10/msg00019.html Manoj > Srivastava pointed out that, "c2man has been dead upstream for years > (which was, so far, not a problem), and does not work with modern > C/C++ programs -- which _is_ a problem. The functionality has been > superseded with packages like doxygen". He wanted to remove c2man > back then (October 2003) but couldn't because some (but few) programs > still used it. > > I'm now filing wishlist bugs on these three packages. Once you have > migrated to doxygen (or something else), I will ask for the removal of > c2man. >

2 1

Could not load c:\windows\system\opengl32.dll Wine 20050524
by J. Grant June 12, 2005

June 12, 2005

Hello, I am expericing a problem due to updating my wine to 20050524 debian unstable package from wine 20050310. I think there could be a bug as OpenGL stopped working. I have included the info below, so hope someone will be able to confirm, or point me in the right direction if I need to revise my previously all working config. I could not find any mention of OpenGL config of wine, this is the only mention i found: http://www.sdconsult.no/linux/wine-doc/opengl-configure.html I tried this suggestion, it did not fix the problem. I wonder why my wine install stoped replacing opengl32.dll ? My nvidia kernel module is functioning fine, glxgears gives me 700FPS, and direct renderering is enabled etc. Call of duty ran fine before I installed this new package. Please include my email address in any replies. Kind regards JG COD MP 1.5 build win-x86 Nov 10 2004 ----- FS_Startup ----- [...] ----- Initializing Renderer ---- ------------------------------- ----- Client Initialization Complete ----- ----- R_Init ----- Initializing OpenGL subsystem ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 1024x768 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 800x600 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL Forcing 640x480 resolution to allow OpenGL to run in fullscreen ...initializing QGL ...calling LoadLibrary( 'c:\windows\system\opengl32.dll' ): failed ...shutting down QGL ----- CL_Shutdown ----- RE_Shutdown( 1 ) ----------------------- Hunk_Clear: reset the hunk ok Could not load OpenGL. Make sure that you have the latest drivers for your video card from the manufacturer's web site. $ wine ./CoDMP.exe trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\user32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wsock32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"C:\\opt\\games\\CoD\\mss32.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\ddraw.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "gdi.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "user.exe" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\winex11.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\imm32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "mmsystem.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\msacm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\msacm.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\midimap.drv" : builtin fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. Wine exited with a successful status

3 5

MSVCRTD/tests/debug.c: buggy call to operator new
by Saulius Krasuckas June 12, 2005

June 12, 2005

Wrong value of 0 (_FREE_BLOCK) is passed as a second parameter (int nBlockUse) to the operator [1], which causes real DLL on real windows to pop up a MSVCRTD Library window, informing you: | Debug Error! | Error: memory allocation: bad memory block type. The test succeeds only on Wine: | void test_new(void) | { | void *mem; | | mem = pMSVCRTD_operator_new_dbg(42, 0, __FILE__, __LINE__); | ok(mem != NULL, "memory not allocated\n"); | } The bug sits here already for one year [2] minus one week [3]. It causes long timeouts during run of Winetest. I hate it. Here goes my patch. I left inability of our operator to differentiate between memory block types (and to handle wrong types) untouched [4]. Hence, I warn about a possible bug in the MSVCRTD_operator_new_dbg(). Is the patch OK? Do I hide the bug? If yes, how should I cope with exceptions in Wine? What else can I do to avoid MSVCRTD Library poping up error window? [1] http://msdn.microsoft.com/library/shared/deeptree/asp/rightframe.asp?dtcfg=… [2] http://www.winehq.com/hypermail/wine-cvs/2004/05/0184.html [3] http://test.winehq.org/data/200406181000/ [4] http://msdn.microsoft.com/library/shared/deeptree/asp/rightframe.asp?dtcfg=… Index: dlls/msvcrtd/tests/debug.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrtd/tests/debug.c,v retrieving revision 1.1 diff -p -u -r1.1 debug.c --- dlls/msvcrtd/tests/debug.c 18 May 2004 01:05:36 -0000 1.1 +++ dlls/msvcrtd/tests/debug.c 12 Jun 2005 20:54:38 -0000 @@ -23,6 +23,7 @@ #include "windef.h" #include "winbase.h" #include "winnt.h" +#include "crtdbg.h" #include "wine/test.h" @@ -55,7 +56,7 @@ void test_new(void) { void *mem; - mem = pMSVCRTD_operator_new_dbg(42, 0, __FILE__, __LINE__); + mem = pMSVCRTD_operator_new_dbg(42, _NORMAL_BLOCK, __FILE__, __LINE__); ok(mem != NULL, "memory not allocated\n"); }

1 0

icons for wine
by David Christian Berg June 12, 2005

June 12, 2005

Hey guys, I don't see a chance of the drawing of icons being accepted as a summer of code project, but still I think that my eXperience icons might just be what wine is looking for. They are SVGs, created with Inkscape. Check them out at http://home.tu-clausthal.de/~dcb/linux/experience/icons.tar.gz there you'll find the latest version. Please CC me for your comments since I'm not on the list. Take care David Christian Berg

2 2

Some economic analysis of Apple's move to x86
by Scott Ritchie June 12, 2005

June 12, 2005

Hey team, After thinking about it a lot and discussing it extensively in IRC and with a few other knowledgeable people, I think it's time to share my economic analysis of the impact of Apple's decision to move to x86 as it relates to us. In short, Apple's move is nothing short of a tremendous potential boon. Getting Wine to work on OSX-x86 is probably one of the easier projects to do, and most of the work has been done already by the Darwine project, such as a Cocoa layer in XCode for the various graphical pieces they've created. While XCode objective C isn't importable to the main tree, most of Wine is portable to OSX-x86 very easily. X11, while not installed by default, works just as well on OSX as it does on Linux, and unlike most projects we don't need to worry too much about adopting the OSX look and feel, since we can't do that for applications that need to look and feel like Windows to behave properly. That said, Darwine needs to remain a fork, though perhaps a more closely-related one. We might want to host or link them more from the main page. What's needed for Darwine that isn't needed for Wine are some OSX specific things - OSX doesn't use the freedesktop.org standards, for instance, so it will have to be specially coded for. I hope to soon be working on some of the freedesktop things for Wine (such as getting that infernal start menu working in Gnome), but that's a different matter for now. Anyway, Apple's decision has fundamentally changed Wine's market environment in a way that's extremely friendly to us. With the Mac users going to Intel, the number of potential Wine users has somewhere between tripled and quintupled, and all we have to do to get them is some relatively easy Cocoa work that's mostly done already. More economically visible than the user base, however, is the almost overnight growth in Wine's potential market Apple's decision has caused. Right now, there are quite a few small firms roughly the size of Codeweavers that make a majority of their money JUST porting games from Wintel to OSX on PowerPC. As we know, porting these programs with Wine is far more efficient than rewriting the code from scratch to use completely different APIs, even if we have to expand Wine a little in the process. Moreover, as Wine gets better and better it becomes increasingly easier to port applications - I'm sure our users (and Transgaming's customers) wouldn't mind games working better in the free version of Wine. In economic terms, that not only means that our production technology is much better, it means we face increasing returns to scale: we can provide the same service cheaper, and the advantage is increasingly ours the more we do it. Simply put, with Apple's move to x86 companies using Wine now have the potential to displace these small porting firms very quickly. Since Codeweavers is currently the only company of Wine experts out there, I can't think of a better firm to enter this newly changed market. If I were Codeweavers, I'd strongly consider investing in a Cocoa developer and a development kit, and put him to work making a Cocoa version of the Crossover interface. At the very least, I'd give Apple a call and see if they have any desire to help. And Apple should be helping a lot. Now, I can't be sure if Codeweaver's don't have a secret agreement with Apple already (it would certainly be Apple's style), nor can I be sure that Apple isn't already secretly forking Wine (much like they did with Konqueror). However, the point still stands - in about a year's time, when Macs on the x86 are being sold, Longhorn still isn't out, and Wine is a stable, functional, and usable piece of free software, things are really going to shake up. Now, firms that stand to lose out by this shakeup may be in a bit of a daze right now. They might try and deny it will ever happen, claiming Wine will never be good enough, or usable enough, or whatever, but we can all see the writing on the wall from here - the Mac Porting firm is fundamentally doomed unless they embrace our new, cheaper technology. If I had a bit of capital or a rich friend, I might even buy one of those firms myself, turn them into Wine people, help perfect Wine's gaming support, and conquer the world of porting software to OSX on the cheap. Thanks, Scott Ritchie -YokoZar

3 8

KERNEL32/tests/console.c: suspending Ctrl-C handling
by Saulius Krasuckas June 12, 2005

June 12, 2005

This is done by calling SetConsoleCtrlHandler(NULL, TRUE). However, MSDN is correct at saying NULL won't work on win9x. I guess win9x intreprets NULL as a handler address w/o any checks and installs it into some chain. When we call GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0) later, we get some weird unhandled exception. How should we get rid of exception? BTW, while being debugged with MSVC, I get no exception thrown by test-process. So, there should be at least one way to get around this exception -- to attach some debugger helper-process and handle it. MSDN mentions DBG_CONTROL_C exception and EXCEPTION_DEBUG_EVENT event. And I am too unfamiliar with this area to repair the tests right now. Any thoughts? Anyone working on this?

1 0