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

wineserver CreateFile flags
by Andreas Mohr June 13, 2005

June 13, 2005

Hi, the create_file request checks for GENERIC_READ or GENERIC_WRITE, but not for GENERIC_ALL. http://groups.google.de/group/microsoft.public.vc.language/browse_thread/th… Documented on MSDN via http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/… --> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/… --> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/s… This might be an issue since some programs might want to do a CreateFile call with GENERIC_ALL. Only few programs do, however, and there is a reason for it: http://groups.google.de/group/microsoft.public.vc.language/browse_thread/th… indicates that GENERIC_ALL is problematic, so maybe it's not too bad that wineserver doesn't support it properly. JFYI, Andreas

2 1

Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3)
by Christian Costa June 13, 2005

June 13, 2005

IFAIK, no... Christian > Message du 13/06/05 16:47 > De : "Mike Hearn" > A : wine-devel(a)winehq.com > Copie à : > Objet : Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3) > > On Mon, 13 Jun 2005 14:59:37 +0200, Alexandre Julliard wrote: > > > Changelog: > > > Added FFMpeg video wrapper filter. > > > > You should dlopen the library to avoid creating a run-time dependency. > > I was under the impression that libavcodec did not have a stable API > anyway. I thought it was simply a place to copy/paste code from. Has that > changed? > > thanks -mike > > > >

1 0

wine and gdi+
by Michael Büttner June 13, 2005

June 13, 2005

Hi, I was checking wine for GDI+ support and noticed that there are no headers or anything at all. I did not find any further information, so i guess there's no work being done there? So, winelib is not an option. What about using wine and native gdiplus.dll, any experiences? What about the license? The one shipped with the gdiplus package I got says says you may use/redistribute gdiplus.dll solely for windows, has anybody ever seen a less restrictive version of that? thx, michael

4 4

Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3)
by Alexandre Julliard June 13, 2005

June 13, 2005

Christian Costa <titan.costa(a)wanadoo.fr> writes: > Moved avcodec.h include into the #ifdef section. > > Changelog: > Added FFMpeg video wrapper filter. You should dlopen the library to avoid creating a run-time dependency. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: crypt32: add CertAlgIdToOID/CertOIDToAlgID
by Alexandre Julliard June 13, 2005

June 13, 2005

Juan Lang <juan_lang(a)yahoo.com> writes: > ChangeLog: add CertAlgIdToOID/CertOIDToAlgID, with tests Unless you have a lot more OID functions to implement, I'd suggest to merge that code in one of the existing files. We don't want to create a new file for just a couple of small functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

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 13, 2005

June 13, 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 13, 2005

June 13, 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 13, 2005

June 13, 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

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

avifil32, msvfw32 and friends
by Jan Jezabek June 12, 2005

June 12, 2005

Hi, What is the current state of VfW support? I have tried a few applications, and they seem to fail sooner or later: - virtualdub runs fine, but it's only possible to use RGB, cvid or ms video. I installed the xvid and divx vfw dll's to wine's c:\windows\system, updated the Drivers32 and drivers.desc keys in the registry, but virtualdub still doesn't let me use them, - 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. My question is: how much of msvfw32.dll and avifil32.dll is implemented? I've had a quick look at msvfw32 and it seems to do what I expected - enumerate all strings from HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32. Does anyone know why the drivers then fail to show up in VirtualDub? Are there any parts of the AVI reader implemented or are they only stubs? Regards, JJ

2 4

Re: server: Return old privileges in adjust_token_privileges
by Robert Shearman June 12, 2005

June 12, 2005

James Hawkins wrote: >Hi, > >NtAdjustPrivilegesToken returns the old privileges of the token in the >PreviousState parameter before replacing them with the privileges in >NewState. > >Changelog >* Return old privileges in adjust_token_privileges. > > Hi James, The code should already do what you are trying to do. The function token_adjust_privileges copies the previous state of the privilege to the output buffer and this works fine in the tests I have done. What is the problem you are seeing? -- Rob Shearman

2 1

Wine could cut the heart out of the Mac game business?
by Tom Wickline June 11, 2005

June 11, 2005

Anyone here care to speculate on what Wine on the future Apple x86 will bring to that platform gloom or doom ? The reason why I ask is, while reading the article "Game Developers React To Intel Switch" Wine in mentioned twice once by "Glenda Adams - Aspyr Media" "Tech Support is one big issue that crops up with emulators as well. If you are playing Sims 2 under some wine-like emulator on OS X Intel, will EA answer you call/email if you have problems? Or will they say its not a supported config?" And at the end of this article there is a Anonymous Developer and here is the quote. "Anonymous Developer: it all depends on WINE and the ability to run PC games on the Mac. it could cut the heart out of the Mac game business." http://www.insidemacgames.com/features/view.php?ID=355 Tom

2 1

OK I give up
by Gregory M. Turner June 11, 2005

June 11, 2005

How do I run the wine test suite under Windows again? I want to do this by compiling from source. I know the answer is out there -- maybe I have even asked this once before and been given the answer? But I can't find it for the life of me. -- gmt

3 3

cannot build tests on windows
by Saulius Krasuckas June 11, 2005

June 11, 2005

As I have updated my wine tree from cvs and recompiled it, now I load the "shell32_test.dsw" into MSVC 6.0, press F7 and get linking errors: | Deleting intermediate files and output files for project 'shell32_test - Win32 MSVC Headers'. | --------------------Configuration: shell32_test - Win32 MSVC Headers-------------------- | Compiling... | generated.c | E:\wine\dlls\shell32\tests\generated.c(9) : warning C4005: '_WIN32_IE' : macro redefinition | unknown(0) : see previous definition of '_WIN32_IE' | shelllink.c | shellpath.c | shlfileop.c | shlfolder.c | string.c | testlist.c | Generating Code... | Linking... | shlfolder.obj : error LNK2001: unresolved external symbol _winetest_ok | string.obj : error LNK2001: unresolved external symbol _winetest_ok | generated.obj : error LNK2001: unresolved external symbol _winetest_ok | shelllink.obj : error LNK2001: unresolved external symbol _winetest_ok | shellpath.obj : error LNK2001: unresolved external symbol _winetest_ok | shlfileop.obj : error LNK2001: unresolved external symbol _winetest_ok | shlfolder.obj : error LNK2001: unresolved external symbol _winetest_set_location | string.obj : error LNK2001: unresolved external symbol _winetest_set_location | generated.obj : error LNK2001: unresolved external symbol _winetest_set_location | shelllink.obj : error LNK2001: unresolved external symbol _winetest_set_location | shellpath.obj : error LNK2001: unresolved external symbol _winetest_set_location | shlfileop.obj : error LNK2001: unresolved external symbol _winetest_set_location | shelllink.obj : error LNK2001: unresolved external symbol _winetest_loop_todo | shelllink.obj : error LNK2001: unresolved external symbol _winetest_end_todo | shelllink.obj : error LNK2001: unresolved external symbol _winetest_start_todo | shelllink.obj : error LNK2001: unresolved external symbol _winetest_trace | shlfileop.obj : error LNK2001: unresolved external symbol _winetest_trace | string.obj : error LNK2001: unresolved external symbol _winetest_trace | shellpath.obj : error LNK2001: unresolved external symbol _winetest_interactive | shellpath.obj : error LNK2001: unresolved external symbol _winetest_get_mainargs | LIBCMTD.lib(crt0.obj) : error LNK2001: unresolved external symbol _main | Output\Win32_MSVC_Headers/shell32_test.exe : fatal error LNK1120: 9 unresolved externals | Error executing link.exe. | | shell32_test.exe - 22 error(s), 1 warning(s) Any ideas on what can be wrong? I have been doing this only on rare occasions in the past, so have no idea weather this is bug, regression or not.

2 1

Re: [QUARTZ] Add FFMpeg video wrapper filter
by Joerg Mayer June 10, 2005

June 10, 2005

On Fri, Jun 10, 2005 at 12:19:06AM +0100, Christian Costa wrote: > This wrapper only support rle, msvideo1 and mjpeg for now. > To enable support for it, download lastest FFMpeg package, built it and > install it. > Also copy avcodec.h, rational.h and common.h into a ffmpeg directory > created in a > standard directory (/usr/include or /usr/local/include). > Once done, run configure to detect the library and the headers. > The library is static so there is no runtime dependency. I haven't looked at libffmpeg as a standalone library, but in case it's possible to do so, maybe runtime detection would be the way to go. That way wine binaries can be delivered without being patent challenged and video support can be added by just installing an additional dynamic lib. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

3 2