January 2003 - Wine-Devel - list.winehq.org

Re: getting started

by Dimitrie O. Paun

On January 10, 2003 01:14 am, Glen Kaukola wrote: > All they have is C++ code. So maybe I should go with my > original plan of compiling stuff with visual studio and seeing if it > runs under wine. Or do you have any other suggestions? Compiling stuff with visual studio is a first step. But it should be very simple to do a Makefile for the examples, how many files do you have in one example? Here is an example Makefile that you can use under mingw: (let me know if it doesn't work, I just typed it inline here, no testing) >--------------- cut here ------------------------< CC = gcc # change this to winegcc under Wine CXX = g++ # change this to wineg++ under Wine RC = windres # change this to wrc under Wine # There six lines will change between examples TARGET = sample1.exe #name of the executable SRCS = file1.cpp file2.cpp ... RSRC = res1.rc res2.rc ... # If you need to add defines, add them to CPPFLAGS # CPPFLAGS, INCDIRS, LIBDIRS, and LIBS may change between examples CPPFLAGS = # add stuff here like -D_WIN32_IE=0x0400 CFLAGS = -mno-cygwin -W -Wall -g -gstabs+ -fno-exceptions -fno-rtti LDFLAGS = -mno-cygwin -mwindows INCDIRS = # add stuff there like -I../include LIBDIRS = # add stuff like -L../lib LIBS = -lcomctl32 # we'll need to add more libs in here for sure OBJ = $(SRCS:.c=.o) $(RSRC:.c=.o) %.o : %.rc $(RC) $(CPPFLAGS) $< $@ %.o : %.cpp $(CXX) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $< %.o : %.c $(CC) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $< $(TARGET): $(OBJS) $(CXX) $(LDFLAGS) $(LIBDIRS) $(LIBS) -o $@ $(OBJS) # A few nice targets all: $(TARGET) clean: rm -f $(TARGET) $(OBJS) >--------------- cut here ------------------------< It's not hard, just look in the .dsp project to see what you need to put in these variables. -- Dimi.

Jan. 10, 2003

PATCH - Define needed flags when building for Mingw

by Steven Edwards

Dont know if this is right or not as you all know I think configure is a little whore. =P Maybe this should go somewhere else. I have about 12 or 13 other things that need to be fixed when building WINE for Mingw and MSYS and I am tired of doing ./configure CFLAGS="-D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" Maybe someone can suggest a better way rather than -DWINE_NOWINSOCK? Thanks Steven Changelog: add defines for Mingw cvs diff -u configure Index: configure =================================================================== RCS file: /home/wine/wine/configure,v retrieving revision 1.387 diff -u -r1.387 configure --- configure 9 Jan 2003 06:04:33 -0000 1.387 +++ configure 10 Jan 2003 04:55:54 -0000 @@ -11973,7 +11973,8 @@ case $host_os in mingw32*) - CRTLIBS="-lmsvcrt" ;; + CRTLIBS="-lmsvcrt" ; + CFLAGS="=$CFLAGS -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" ; esac cvs diff -u configure.ac Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.119 diff -u -r1.119 configure.ac --- configure.ac 9 Jan 2003 06:04:33 -0000 1.119 +++ configure.ac 10 Jan 2003 04:56:29 -0000 @@ -857,7 +857,8 @@ AC_SUBST(CRTLIBS,"") case $host_os in mingw32*) - CRTLIBS="-lmsvcrt" ;; + CRTLIBS="-lmsvcrt" ; + CFLAGS="=$CFLAGS -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" ; esac dnl **** Get the soname for libraries that we load dynamically **** __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 10, 2003

Re: PATCH - Define needed flags when building for Mingw

by Dimitrie O. Paun

On January 10, 2003 12:01 am, Steven Edwards wrote: > + CFLAGS="=$CFLAGS -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK" ; Why do you need these defines? In particular, isn't the compiler defining __MINGW__ and _WINDOWS? -- Dimi.

Jan. 10, 2003

Re: [RFC] msvcrt: defines break C++ code

by Dimitrie O. Paun

On January 9, 2003 08:38 pm, Alexandre Julliard wrote: > I think you have to link with oldnames.lib for that. We probably have > to provide an oldnames.lib too. OK, but what do we do now about those defines? -- Dimi.

Jan. 10, 2003

Re: prevent dereferencing null

by Bill Medland

On January 9, 2003 03:12 pm, Dimitrie O. Paun wrote: > On January 9, 2003 07:08 pm, Bill Medland wrote: > > + if (!tpinfo->chanbuf) { > > + ERR("tpinfo has no Rpc Channel Buffer\n"); > > + return 0; > > + } > > Is this expected behaviour? If so, there's no need for the ERR msg. > If not, there's no need for the test, we need to fix the root cause... You are, of course, quite correct. I don't know what the expected behaviour is; all I know is that dereferncing the null pointer isn't. If someone actually understands all that proxy stuff then maybe they can do something about it. If not then I guess it is destined to languish unfixed. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 10, 2003

Re: DirectSound and i810 soundcards

by Francois Gouget

Francois Gouget wrote: [...] > 2. if we tweak things so that the CreateThread is done, then the > resampling will be done by Alsa (or whichever back-end) which will > presumably do it much better than us. howeve rin that case we have to > make the almost never used case work and I'm not sure how well it would > work anyway (I'm concerned about skips/cracks/pops). Option 2 turned out to be quite simple to get working so that's what I did. However the result does not work very well. When I run the DirectSound test I get a lot of 'stutter' :-( It seems like there are a lot of underruns. Other applications (e.g. Windows Media Player) seem to work better but that appears to depend on the machine too... It seems we should be able to do better. For those who want to play with this but don't have an i810 souncard (e.g. me), I attached a nice patch that allows you to simulate all sorts of things: * by default the patch has no effect * define I810O="1" (that's an O for OSS) Then the ioctls will return the same results they would return in an i810+OSS combination. This means only 48000x16x2 will be accepted. This simulates what happens in an i810+OSS configuration. * define I810A="1" Then winmm will be able to use all the formats your soundcard supports but mmap will fail if the current format is not 48000x16x2. This simulates what happens in an i810+Alsa configuration. * define NOMMAP="1" Then mmap will systematically fail. This does not simulate a specific configuration I know of but heck, why not. So to run the dsound test as if you had an i810+Alsa configuration you would do: cd dlls/dsound/tests I810A="1" WINETEST_INTERACTIVE="1" ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c Actually doing so you may notice that the i810+Alsa patch I sent to wine-patches does not support writing to the primary buffer (but who does that anyway)... -- Francois Gouget fgouget(a)codeweavers.com Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.70 diff -u -r1.70 audio.c --- dlls/winmm/wineoss/audio.c 7 Jan 2003 23:08:05 -0000 1.70 +++ dlls/winmm/wineoss/audio.c 9 Jan 2003 23:28:33 -0000 @@ -70,6 +70,60 @@ /* Allow 1% deviation for sample rates (some ES137x cards) */ #define NEAR_MATCH(rate1,rate2) (((100*((int)(rate1)-(int)(rate2)))/(rate1))==0) +static int i810_rate=48000; +static int i810_format=16; +static int i810_stereo=1; +static int i810_ioctl(int fd, unsigned long int request, void* data) +{ + if (getenv("I810O")) + { + switch (request) { + case SNDCTL_DSP_SETFMT: + TRACE("simulating i810+OSS: reject non 16bit format (%d)\n",*((int*)data)); + *((int*)data)=AFMT_S16_LE; + break; + case SNDCTL_DSP_STEREO: + TRACE("simulating i810+OSS: reject non stereo format (%d)\n",*((int*)data)); + *((int*)data)=1; + break; + case SNDCTL_DSP_SPEED: + TRACE("simulating i810+OSS: reject unsupported sample rate (%d)\n",*((int*)data)); + *((int*)data)=48000; + break; + } + } + switch (request) { + case SNDCTL_DSP_SETFMT: + i810_format=*((int*)data); + break; + case SNDCTL_DSP_STEREO: + i810_stereo=*((int*)data); + break; + case SNDCTL_DSP_SPEED: + i810_rate=*((int*)data); + break; + } + return ioctl(fd,request,data); +} +#define ioctl(a,b,c) i810_ioctl((a),(b),(c)) + +static void* i810_mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset) +{ + if (getenv("NOMMAP") || + (getenv("I810A") && + (i810_rate!=48000 || i810_format!=16 || i810_stereo!=1))) + { + if (getenv("RtlAcquireResourceExclusive")) + TRACE("simulating lack of mmap support\n"); + else + TRACE("simulating i810+Alsa: reject mmap for non native format (%dx%dx%d)\n",i810_rate,i810_format,i810_stereo); + errno=EIO; + return (void*)-1; + } + return mmap(start, length, prot, flags, fd, offset); +} +#define mmap(a,b,c,d,e,f) i810_mmap((a),(b),(c),(d),(e),(f)) + #ifdef HAVE_OSS #define MAX_WAVEDRV (3)

Jan. 10, 2003

Re: [RFC] msvcrt: defines break C++ code

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > The strange thing is that the MSVC headers simply define their > prototype, e.g.: > > _CRTIMP int __cdecl umask(int); > > Yet these APIs are not exported by the msvcrt library or by any other > dll that I know of. And still applications compile and link! I think you have to link with oldnames.lib for that. We probably have to provide an oldnames.lib too. -- Alexandre Julliard julliard(a)winehq.com

Jan. 10, 2003

Re: Problem in dlls/ddraw/dsufrace/main.c

by Sylvain Petreolle

no problem any more with this code when I updated my CVS (aged from Tuesday morning :) ) black magic ;) --- Lionel Ulmer <lionel.ulmer(a)free.fr> a écrit : > > trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface > > (0x402a9418)->Looking for caps: 4,0,1,1 output: 0x741ed0 > > Caps are : DDSCAPS_BACKBUFFER > > trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Surface: > > (0x402a9b38) caps: 1000601c,0,0,0 > > Surface caps are : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX > DDSCAPS_FLIP > > DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM > > trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Returning > surface > > 0x402a9b38 with description : > > - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP > > DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM > > - DDSD_HEIGHT : 480 > > - DDSD_WIDTH : 640 > > - DDSD_PITCH : 1280 > > - DDSD_LPSURFACE : 0x424b0000 > > - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B > 001f) > > Well, you completely lost me here... Could you restate your problem > from the > beginning ? Because well, in your trace, I see that you actually > FOUND a > valid attached surface. So the 'if (found == NULL)' test will be > FALSE and > thus whether this code is in or not would not change anything at all. > > So I doubt that removing this piece of code would change anything in > the > application's behaviour. > > The only thing I could see would be that you were running with a > quite old > CVS version and when you ugraded you got one fix I did on the > GetAttachedSurface code to handle some problem we had with useless > caps in > the DDSCAPS structure being tested whereas they should not have been. > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 10, 2003

Re: [RFC] msvcrt: defines break C++ code

by Dan Kegel

Dimitrie O. Paun wrote: > I suggest we turn those defines into inlines, like this: > > inline int write(int fd, const void* ptr, unsigned int size) { return _write(fd, ptr, size); } > > Any other solutions? Sure, there are two: 0. use a linker alias for _write 1. actually have a function write() that just jumps to _write 2. actually have a function write() that calls _write Not sure any of those are better than what you suggest, though. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 10, 2003

Re: [RFC] msvcrt: defines break C++ code

by Francois Gouget

On Thu, 9 Jan 2003, Dimitrie O. Paun wrote: > Folks, > > We have a lot of code in msvcrt headers like so: > > #define umask _umask > #define unlink _unlink > #define write _write [...] > I suggest we turn those defines into inlines, like this: > > inline int write(int fd, const void* ptr, unsigned int size) { return _write(fd, ptr, size); } > > Any other solutions? The strange thing is that the MSVC headers simply define their prototype, e.g.: _CRTIMP int __cdecl umask(int); Yet these APIs are not exported by the msvcrt library or by any other dll that I know of. And still applications compile and link! In fact it seems that whether the application calls umask or _umask (even once preprocessed), MSVC will import _umask. Anyway, replacing these defines with inline functions is fine with me. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Jan. 10, 2003