- Wine-Devel - list.winehq.org

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

Dragon NS8 on wine
by René Rebe June 12, 2005

June 12, 2005

Hi all, despite my inital problems with the setup.exe of Naturally Speaking 8 wanting to install and USB 2 (EHCI) stack which failed due to "OS not supported" I found out that it is possible to run the .msi Microsoft Installer manually: Install the Microsoft Installer as downloadable somewhere at microsoft.com: wine InstMsiA.exe cd /media/cdrom # or where your wine CD-ROM is wine msiexec /i ISScript9.Msi # some script engine needed wine msiexec /i "Dragon NaturallySpeaking 8.msi" However the I still tinker to start the real applications when installed ... The audio.exe works - itz can adjust the microphone gain and I get a signal to noise ration of 24. However starting natspeak.exe yields: $ wine ./natspeak.exe fixme:vxd:VXD_Open Unknown/unsupported VxD L"bcmdmccp.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"smartvsd.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"smartvsd.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"smartvsd.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"smartvsd.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"sice.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"ntice.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"siwdebug.vxd". Try setting Windows version to 'nt40' or 'win31'. fixme:vxd:VXD_Open Unknown/unsupported VxD L"siwvid.vxd". Try setting Windows version to 'nt40' or 'win31'. Segmentation fault (core dumped) When I set the winver to nt40 I get: $ wine natspeak.exe err:seh:setup_exception nested exception on signal stack in thread 0009 eip 401b06a9 esp 401d3cf8 stack 0x405d0000-0x406d0000 ... Idea anyone? Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45

1 0

Re: [NtQuerySystemInformation #7] SystemTimeOfDayInformation (RESEND)
by Alexandre Julliard June 12, 2005

June 12, 2005

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > just found at that the behavior of NT and W2K/WinXP differ a lot for > SystemTimeOfDayInformation. > > The struct for NT is 32 Bytes compared to 48 for the others. Apart from > that returncodes etc.. are totally different. > > The included test explains (some of) the differences. > > The test now also caters for all the above mentioned versions, as does > nt.c (that means setting the wine version to nt4 produces the correct > results). > > nt.c now has a hard coded value for the size of the struct for NT (32). You should not do that kind of version-dependent code unless there is an app that requires it. Otherwise just implement the XP behavior, which should be backwards compatible anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

(no subject)
by michaelguennewig＠gmx.de June 12, 2005

June 12, 2005

To: Jan Jezabek <jezabek(a)poczta.onet.pl> Cc: wine-devel(a)winehq.com Subject: Re: avifil32, msvfw32 and friends References: <d87f0s$5eh$1(a)sea.gmane.org> <d8debr$v55$1(a)sea.gmane.org> From: Michael Guennewig <michael(a)voldemort.guenne-net.loc> Date: 12 Jun 2005 11:07:29 +0200 In-Reply-To: <d8debr$v55$1(a)sea.gmane.org> Message-ID: <m3r7f8osdq.fsf(a)voldemort.guenne-net.loc> Lines: 43 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jan Jezabek <jezabek(a)poczta.onet.pl> writes: > Jan Jezabek wrote: > > Hi, > > What is the current state of VfW support? I have tried a few > > applications, and they seem to fail sooner or later: > > - I've also got a program written by me, which reads an AVI and > > stores the video part on disk. Here the problem seems to be > > AviFileInit which seems not to be implemented. AviFileInit isn't implemented currently as the library is hard-linked to ole32.dll. > > Are there any parts of the AVI reader implemented or are they only stub= s? Most of the code should be in when I remember correctly. As far as I know the remote stuff, like the marshaller and proxy is missing. As well as it= =20 still is not thread safe. >=20 > Ok, this post was probably better suited for the 'users' list. Anyway, > I've posted a patch that solves the first issue. > The second one is a little harder; it works ok using builtin msvfw32 > and native (winXP) avifil32.dll. With the builtin avifil32.dll I can > open an AVI, get a video stream, read its format (dimensions > etc.). After that I get a segfault somewhere in AviStreamGetFrame. Is > this (AviStreamGetFrame) supposed to be working? Or is it partially > implemented/broken? It seems that the AVI (or at least the header) is > being parsed correctly. The IGetFrame interface uses the msvfw32.dll and the video codecs. It work= ed for some codecs that I have tried in past as I have written it, but it may = be that either a regression occured or that the video codec you are using just returns a NULL pointer where the code does not expect it. I could try to remember what I have written and support you to fix it, but I would need mo= re informations. Like which video codec, programm, AVI headers and which meth= ods=20 gets called and where does it segfaults. For the last parts it would be ni= ce=20 if you could send me a trace which shows msvfw32 and avifil32 calls. Regards, Michael G=FCnnewig

1 0

Dragon NS7 on wine
by wino＠piments.com June 12, 2005

June 12, 2005

Sorry Rene, I thought this thread should have a title that related to Dragon. By all means continue your v8 attempts under ViaVoice alias. ;) you have restimulated my interest in this so I will push ahead with v7 since I did not have some of the issues you are having with v8. I'm pretty sure the guts of the thing are identical as far as speach rec. technology goes. Recap: * app-emulation/wine : [ I] 20041019-r3 (0) .wine/config attached This is on a clean installation of the above version. I copied the config from a prev installation but I dont think there any magic. Installed from a CD using : WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n" wine h:setup.exe No issues at all with installshield. One thing to note is to move all dlgs to one side since at some stage there is a yes/no modal dlg that pops up centre screen but does not come to the top of the z-order. Since it is hidden behind the logo/dlg and it does not have the focus you cannot access it. I deselected the quickstart option and the Text to speach files and opted for UK English lang model. Once install finished I did wineboot and got the following: prof(a)newsys ~/.wine/c $ wineboot fixme:ddeml:DdeConnectList (1,0xc000,0xc000,(nil),(nil)): stub fixme:ddeml:DdeQueryNextServer (0x1,(nil)): stub fixme:ddeml:DdeDisconnectList (0x1): stub err:wineboot:runCmd Failed to run command (0) err:wineboot:ProcessRunKeys Error running cmd #1 (0) Did not dig for detail m but I dont think there is anything critical there. (We are not expecting DDE to work!) Now the sticky bit : wine natspeak.exe fixme:vxd:VXD_Open Unknown/unsupported VxD L"nwlink.vxd". Try setting Windows version to 'nt40' or 'win31'. err:toolbar:TOOLBAR_TestImageExist index 8 is not valid, max 8 err:toolbar:TOOLBAR_TestImageExist index 9 is not valid, max 8 ............ fixme:mixer:MIX_GetLineInfo Unhandled component type (MIXERLINE_COMPONENTTYPE_DST_VOICEIN) fixme:mixer:MIX_GetLineInfo Unhandled component type (MIXERLINE_COMPONENTTYPE_DST_VOICEIN) fixme:mixer:MIX_GetLineInfo Unhandled component type (MIXERLINE_COMPONENTTYPE_DST_VOICEIN) This seems similar to the probs Rene Rebe reported with ViaVoice. Apart from this the Dragon tool bar comes up cleanly and allows me to open DragonPad editor. There seems to be no other major issues which is promising. I was able to short circuit this issue with NS v4 by skipping the audio setup and running gentrain.exe directly since the real prerequisit is to run the user training setup. Running the training through natspeak (which is reqd. before you can do anything with the mike) first tries to set the mike level and we stump. Two approaches seem possible: 1/ Set the mike level in Linux and con NS that is has been set. 2/ Resolve the technical issue with wineoss / winealsa so that it can control the mike and do what it "thinks" it needs to do. 2 is ultimately what needs to be done but is out of my hands. 1 seems more accessible but last time I looked I did not find anything in the ini files , probably need to do some reg hacking. Poss with ref to a true wine install of v7 Ideas / thoughts... Regards.

2 13