wine-devel March 2004

wine-devel@winehq.org

128 participants
264 discussions

kernel32.dll.so isn't work with video for window(AVIMakeCompressedStream)
by kscho 04 Mar '04

04 Mar '04

Hi~, I runed avi related program work with wine-20040121, It works fine. thanks this~ but I tested wine-20040213, AVIMakeCompressedStream isn't work properly, therefore not returned GetAvailableSystemCodec in my function. below is my test code. when i replace kernel32.dll.so (in the wine-20040121) it works. How can I do? thanks in advance -----------------------my test code ------------------------------ #define AVIIF_KEYFRAME 0x00000010L // this frame is a key frame. static const struct tREC_FOURCC{ FOURCC fcc; char *name; } recommended_fcc[] = { { mmioFOURCC('m','p','4','3'), "mpeg4_3" }, // Microsoft MPEG4 V3 { mmioFOURCC('m','p','4','2'), "mpeg4_2" }, // Microsoft MPEG4 V2 { mmioFOURCC('d','i','v','x'), "divx" }, { mmioFOURCC('I','V','5','0'), "indeo_5" }, { mmioFOURCC('I','V','4','0'), "indeo_4" }, }; static char empty_audio_frame[SAMPLED_SMSIZE_8*4]; BOOL GetAvailableSystemCodec(PAVIWRITER paw) { int i; if(paw->ip.flags & AW_CODEC_FORCCC) { paw->opts.fccHandler = paw->ip.codecFourcc; paw->codec_name = NULL; if(AVIERR_OK == AVIMakeCompressedStream(&paw->psCompressed, paw->ps, &paw->opts, NULL)) { return TRUE; } } memset(&paw->opts, 0, sizeof(paw->opts)); for(i=0; i<sizeof(recommended_fcc)/sizeof(struct tREC_FOURCC); i++) { paw->opts.fccHandler = recommended_fcc[i].fcc; paw->codec_name = recommended_fcc[i].name; if(AVIERR_OK == AVIMakeCompressedStream(&paw->psCompressed, paw->ps, &paw->opts, NULL)) { return TRUE; } } return FALSE; }

1 0

run authenticated over a NT domain aplications
by Marco Rodriguez M. 03 Mar '04

03 Mar '04

Hi , i'm traying to run with wine a legacy aplication that needs to be run by a loged in user under NT Domain. That aplication needs to be authenticated on the server to access the SQL server. Looking on google i've found a post about logonUser patch from Martin Wilks ( http://www.winehq.org/hypermail/wine-patches/2002/11/0110.html) that works with pam and winbind. Whi this patch was removed from the development? Is there any other way to run aplications of those? Are there some one who can help me to or have a tutorial or a HOWTO to run this kind of aplications? Or maybe i'ts imposible for now.... i hope not, this is very improtant to completely migrate propietary aplication an legacy sistem to O.S. T.I.A. -- Marco Rodriguez M. marco[(a)]ubiobio.cl U. Bio Bio Concepcion Chile

1 0

Re: Re: Native NetBSD audio driver
by wine＠frotz.org 03 Mar '04

03 Mar '04

> What is the plan for combining these audio drivers? One thing that is common > to each driver are the functions that handle the wave headers, adding, > removing > etc. I understand the desire to extract common code from drivers that have largely been cut and paste from the OSS driver's boilerplate, but I hope this merge won't restrict new drivers to an implementation that uses this boilerplate. I'm developing from the ground up a new ALSA/OpenAL driver which I intend to provide a "best quality" PCM DirectSound experience for gaming. The driver uses ALSA's DMIX plugin device, so it should interoperate with similarly configured arts, jack, etc. servers. It supports secondary buffers and 3D. The intent is to take advantage of HW support for these features when available. As yet I have had no need to reuse code from the OSS driver. Legacy waveOut/ waveIn interfaces will be implemented using the driver's DirectSound interfaces. The driver is very pre-alpha and development is admittedly very slow. However, when it is ready -- if there is interest -- I would like to post it to wine-patches for code review and addition to CVS. --d

1 0

ImmAssociateContextEx missing
by Jesse Allen 03 Mar '04

03 Mar '04

Hi, I have noticed that when you load up Warcraft III, and then quit the game, that it will pop up with a messagebox error message complaining about a memory location, 0xdeadbeef. I have also noticed this message: err:win32:PE_fixup_imports No implementation for imm32.dll.2(ImmAssociateContextEx) imported from C:\war3\war3.exe, setting to 0xdeadbeef I looked for ImmAssociateContextEx in imm32, and its not there, not even in the imm32.spec file. I implemented a stub for ImmAssociateContextEx, and then ran the game. It now comes up with my stub message upon exiting the game: fixme:imm:ImmAssociateContextEx (0x20021, (nil), 16): stub So apparently war3.exe has a reference to ImmAssociateContextEx, and detects the bad address, and immediately exits with an error. Applying the patch allows the game to exit normally. I have the patch attached. Any comments? Jesse --- wine/dlls/imm32/imm.c 2004-03-02 13:55:57.000000000 -0700 +++ wine-new/dlls/imm32/imm.c 2004-03-02 16:49:23.000000000 -0700 @@ -255,6 +255,15 @@ } /*********************************************************************** + * ImmAssociateContextEx (IMM32.@) + */ +BOOL WINAPI ImmAssociateContextEx(HWND hWnd, HIMC hIMC, DWORD dwFlags) +{ + FIXME("(%p, %p, %ld): stub\n", hWnd, hIMC, dwFlags); + return FALSE; +} + +/*********************************************************************** * ImmConfigureIMEA (IMM32.@) */ BOOL WINAPI ImmConfigureIMEA( --- wine/dlls/imm32/imm32.spec 2004-02-02 17:12:03.000000000 -0700 +++ wine-new/dlls/imm32/imm32.spec 2004-03-02 16:21:47.000000000 -0700 @@ -1,4 +1,5 @@ @ stdcall ImmAssociateContext(long long) +@ stdcall ImmAssociateContextEx(long long long) @ stdcall ImmConfigureIMEA(long long long ptr) @ stdcall ImmConfigureIMEW(long long long ptr) @ stdcall ImmCreateContext()

2 1

Re: Native NetBSD audio driver
by Yorick Hardy 03 Mar '04

03 Mar '04

I started now with the integration of the OSS and NetBSD audio drivers. Before I get too far, I would like to hear suggestions/criticisms. 1) I created the directory dlls/winmm/drvcommon (perhaps there is a better name ?) 2) moved dlls/winmm/wineoss/oss.c and dlls/winmm/winenbsd/nbsd.c to the single integrated file dlls/winmm/drvcommon/drv.c. 3) renamed the files dlls/winmm/wineoss/oss.h and dlls/winmm/winenbsd/nbsd.h to dlls/winmm/wineoss/drv.h and dlls/winmm/winenbsd/drv.h respectively. 4) Update the respective Makefile.in to use the integrated dlls/winmm/drvcommon/drv.c The idea is that eventually winenbsd and wineoss only have the drv.h and the spec file. drv.h will define all driver specific names/functions. I must stress that I am only concerned with the OSS and NetBSD drivers at the moment. Is this too much? Or can someone suggest a better solution? Kind regards, -- Yorick Hardy Tel: +2711 489 3640 | Fax: +2711 489 2067 | Office: C-Ring 517 Auckland Park Campus | Rand Afrikaans University | South Africa Department of Applied Mathematics : http://general.rau.ac.za/apm Standard Bank Academy for Information Technology : http://csweb.rau.ac.za

3 3

Re: SysParametersInfoW->A crosscall (fixed)
by tony_lambregts＠telusplanet.net 03 Mar '04

03 Mar '04

Alexandre, is there any reason that this patch isn't applied? http://www.winehq.org/hypermail/wine-patches/2004/02/0332.html -- Tony Lambregts

2 1

Re: winemaker fixes
by Dimitrie O. Paun 02 Mar '04

02 Mar '04

On Tue, 2 Mar 2004, Francois Gouget wrote: > winemaker is pretty broken since it has been patched to call winegcc. I > suspect it was not tested. Hey, I can't do everything! :))) I just wanted to get the ball rolling. > We must specify '-lmsvcrt' if using the msvcrt. Please don't, it's not needed. If you want to use msvcrt, please pass the -mno-cygwin switch. if that doesn' work, it's a bug in winegcc. > There is still work to do: > > 1. Linking with uuid is broken. I suspect winegcc finds the Unix > /lib/libuuid.so first and links with that instead of with our libuuid.a > library. That shouldn't happen. Can you please run winegcc with the -v flag, and send the output my way please? > 2. wrc does not find 'windows.h' (yes, some RC files #include Win32 > headers). wrc should know about the location of the headers like winegcc > (since our Makefile don't know anything about where the Wine headers are > anymore). I've verified the source and it should. Maybe you can produce a --debug=FF trace? > 4. We have lost the autoconf integration. We should encapsulate our macros so they can conveniently be used by people in their configure.ac scripts. I think that's the proper way to get autoconf integration. > 5. Nothing works if Wine has not been installed. This is quite > impractical for Wine developers. It's true, but there are many reasons you need to install Wine to be able to use Winelib. I doubt it will change in the near future. > 6. winegcc is not rebuilt if the '--prefix' changes. Maybe AJ can fix the Makefile. I think winegcc.o should depend on the Makefile. > 7. Building dlls does not work yet but that was expected and Dimi is > working on it. In progress :) -- Dimi.

3 2

Re: Native NetBSD audio driver
by Eric Pouech 02 Mar '04

02 Mar '04

Yorick Hardy a écrit : > This patch adds the audio driver winenbsd using the native NetBSD > audio system as an alternative to OSS. On the one hand > this is useful to directly make use of the features of the NetBSD > audio system instead of using emulation, on the other hand > it is another driver to maintain and is quite close to the wineoss driver. > If the driver is accepted, I think the NetBSD support for wineoss > should remain for testing and for the main driver. I really think we're starting to create a real mess for the audio drivers. It's always useful to have drivers access the HW at the lowest level, so we should support NetBSD. However, if the iface is rather close to OSS, I'd rather suggest we try to integrate all the drivers with the same features into a single piece of driver > diff -urN /home/yorick/software/wine/wine/dlls/Makefile.in ./dlls/Makefile.in > --- /home/yorick/software/wine/wine/dlls/Makefile.in Sat Feb 14 19:20:00 2004 > +++ ./dlls/Makefile.in Sat Feb 21 23:43:35 2004 > @@ -1745,6 +1749,7 @@ > winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack > msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3 > winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas > +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd *** this should be winenbsd A+

7 8

Cross compiling Wine with MinGW
by Hans Leidekker 02 Mar '04

02 Mar '04

Hi, I spent some time cross compiling all of Wine with MinGW according to this recipe: http://winehq.com/?issue=123#Cross-compiling Wine and I thought you might be interested in the results. I can report a bug in Wine's makefiles right away: having those vxd's in subdirectories that end in .vxd causes make to barf on targets like this one: ifsmgr.vxd$(DLLEXT): ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $(RM) $@ && $(LN_S) ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $@ because, if $(DLLEXT) is empty, it will try to create a link with a name that's already there as a directory. Of all dlls these don't compile: x11drv kernel32 gdi32 ws2_32 comctl32 icmp iphlapi msvcrt ntdll rpcrt4 shlwapi vnb.vxd wininet wsock32 x11drv, kernel32, gdi32 and ntdll being predictable, because they build directly on X11 and Unix API's. Same goes for the networking related dlls (ws2_32, icmp and iphlpapi, vnb.vxd, wininet, wsock32). msvcrt is close to building because what I saw was mostly header clashes, which could be fixed with proper guards I think. rpcrt4 fails because it uses one Unix API, gettimeofday, and both comctl32 and shlwapi suffer from the bug in dlltool that Dmitry reported and fixed recently. -Hans

3 3

Re: Re: Native NetBSD audio driver
by chmorgan＠charter.net 02 Mar '04

02 Mar '04

What is the plan for combining these audio drivers? One thing that is common to each driver are the functions that handle the wave headers, adding, removing etc. I'm also weary of any kind of combination that includes OSS as OSS is depreciated and has been replaced by Alsa. I'm also concerned with the arts, jack and nas drivers being left out of this merge. While many of the audio drivers have a lot in common there are a LOT of subtle differences that are necessary for things to work correctly. Maybe Eric and others could comment on what they see as being able to be combined, although I've worked a bit on audio drivers I'm drawing mostly a blank. Thanks, Chris > > From: Yorick Hardy <yha(a)na.rau.ac.za> > Date: 2004/03/02 Tue AM 04:38:41 EST > To: wine-devel(a)winehq.org > CC: yha(a)na.rau.ac.za > Subject: Re: Native NetBSD audio driver > > I started now with the integration of the OSS and NetBSD audio drivers. > Before I get too far, I would like to hear suggestions/criticisms. > > 1) I created the directory dlls/winmm/drvcommon > (perhaps there is a better name ?) > 2) moved dlls/winmm/wineoss/oss.c and dlls/winmm/winenbsd/nbsd.c > to the single integrated file dlls/winmm/drvcommon/drv.c. > 3) renamed the files dlls/winmm/wineoss/oss.h and dlls/winmm/winenbsd/nbsd.h > to dlls/winmm/wineoss/drv.h and dlls/winmm/winenbsd/drv.h respectively. > 4) Update the respective Makefile.in to use the integrated > dlls/winmm/drvcommon/drv.c > > The idea is that eventually winenbsd and wineoss only have the drv.h > and the spec file. drv.h will define all driver specific names/functions. > I must stress that I am only concerned with the OSS and NetBSD drivers > at the moment. > > Is this too much? Or can someone suggest a better solution? > > Kind regards, > > -- > Yorick Hardy > Tel: +2711 489 3640 | Fax: +2711 489 2067 | Office: C-Ring 517 > Auckland Park Campus | Rand Afrikaans University | South Africa > Department of Applied Mathematics : http://general.rau.ac.za/apm > Standard Bank Academy for Information Technology : http://csweb.rau.ac.za > > >

1 0

Jump to page:

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 March 2004