wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: Chinese text input into Notes R6 Mail field
by Daniel Schwarz 03 May '02

03 May '02

> Actually Aric and Ulrich helped a lot and they provided us the patch you > Codeweavers did for your clients and Aric has > gained permission to open the source. Since he needs to clean up the > code, he suggested to let him post the patch when it's > done. > > I used it to try for Chinese Input on Notes Client r6. Unfortunately, > it only works on some controls. > When I want to type Chinese/Japanese on the mail content area ( do not > know what kind of widget it is), > it doesn't show properly. I think it's a bug. Could you kindly help? > Which segment of code I should trace on? I have not used Notes R6 extensively but based on my understanding of the Notes R4 - R5 code, the mail content area is a Notes Rich Text field, which is implemented internally to Notes. It's not a Windows control therefore will not be responsive to code that hooks into Windows controls. Notes is localized for many countries,including, I think, Chinese, although the Notes R6 Beta is probably US-English only. I suggest you experiment with a copy of Notes R5 with Chinese localization. If you need technical details on how localized versions of Notes handle alternate keyboard input methods, let me know and I'll see what I can dig up. Regards, Dan Schwarz http://www.winecentric.com/wiki The Wine Wiki

3 5

Developers-hints update
by Sylvain Petreolle 03 May '02

03 May '02

Hi, In order to reflect the evolution of the wine tree, I propose the following patch. Comments ? Changelog: Update of DEVELOPERS-HINTS to reflect the current state of Wine. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wineconsole regression on April 4
by Duncan Sands 03 May '02

03 May '02

Wineconsole regressed between 10pm April 3 and 10pm April 4 (GMT). The IDA Pro disassembler (idaw.exe, available from http://www.datarescue.be/downloadfreeware.htm) fails due to changes on this date. This is a console mode program with turbo pascal style windows, for example windows have a little green square as a close box. History: Jan 1 CVS : program runs with good sized font, however bitmaps like the little green square show up as odd characters. Apr 3 CVS : program runs with tiny font, bitmaps are displayed correctly. > Apr 4 CVS : window comes up, disappears, wine exits without an error. (Normal behaviour: window comes up, is resized, initial screen is drawn.) Thus the bug is: wine exits immediately after bringing up the window (but before drawing anything in it). This seems to be due to changes in xfont.c. I offer here a choice of two patches that "fix" this. Surely neither of them is getting to the root cause of the problem. Either works, but with patch 2, the text comes up in a tiny font like with Apr 3 CVS, with patch 1 it comes up in a normal font (but no little bitmaps, like Jan 1 CVS). All the best, Duncan. Patch 1 (also attachment 1). This reverts from using the global variable text_caps to using a local variable XTextCaps. --- bad/graphics/x11drv/xfont.c.orig Wed May 1 09:42:32 2002 +++ bad/graphics/x11drv/xfont.c Wed May 1 09:46:39 2002 @@ -78,6 +78,11 @@ static fontAlias *aliasTable = NULL; +static UINT XTextCaps = (TC_OP_CHARACTER | TC_OP_STROKE | TC_CP_STROKE | TC_CR_ANY | + TC_SA_DOUBLE | TC_SA_INTEGER | TC_SA_CONTIN | + TC_UA_ABLE | TC_SO_ABLE | TC_RA_ABLE); + /* X11R6 adds TC_SF_X_YINDEP, maybe more... */ + static const char* INIFontMetrics = "cachedmetrics."; static const char* INIFontSection = "Software\\Wine\\Wine\\Config\\fonts"; static const char* INIAliasSection = "Alias"; @@ -948,7 +953,7 @@ aLFD.resolution_x = resx_string; strcpy(resy_string, resx_string); - if( uRelax == 0 && text_caps & TC_SF_X_YINDEP ) + if( uRelax == 0 && XTextCaps & TC_SF_X_YINDEP ) { if( fo->lf.lfWidth && !(fo->fo_flags & FO_SYNTH_WIDTH)) { @@ -2424,7 +2429,7 @@ fontInfo* pfi = pfm->pfi; /* device font to match */ LPLOGFONT16 plf = pfm->plf; /* wanted logical font */ UINT penalty = 0; - BOOL bR6 = pfm->flags & FO_MATCH_XYINDEP; /* from text_caps */ + BOOL bR6 = pfm->flags & FO_MATCH_XYINDEP; /* from XTextCaps */ BOOL bScale = pfi->fi_flags & FI_SCALABLE; int d = 0, height; @@ -2947,7 +2952,7 @@ strcpy(buffer, "-*-*-*-*-normal-*-[12 0 0 12]-*-72-*-*-*-iso8859-1"); if( (x_fs = TSXLoadQueryFont(gdi_display, buffer)) ) { - text_caps |= TC_SF_X_YINDEP; + XTextCaps |= TC_SF_X_YINDEP; TSXFreeFont(gdi_display, x_fs); } } @@ -2980,7 +2985,7 @@ XFONT_GetPointResolution( log_pixels_x, log_pixels_y ); if(X11DRV_XRender_Installed) - text_caps |= TC_VA_ABLE; + XTextCaps |= TC_VA_ABLE; return; } @@ -3055,7 +3060,7 @@ fm.plf = plf; fm.internal_charset = internal_charset; - if( text_caps & TC_SF_X_YINDEP ) fm.flags = FO_MATCH_XYINDEP; + if( XTextCaps & TC_SF_X_YINDEP ) fm.flags = FO_MATCH_XYINDEP; /* allocate new font cache entry */ ------------------------------------------------------------------- Patch 2 (also attachment 2). BOTH lines need to be changed. --- bad/graphics/x11drv/xfont.c.orig Wed May 1 09:42:32 2002 +++ bad/graphics/x11drv/xfont.c Wed May 1 09:15:35 2002 @@ -2978,6 +2978,7 @@ void X11DRV_FONT_Init( int *log_pixels_x, int *log_pixels_y ) { XFONT_GetPointResolution( log_pixels_x, log_pixels_y ); + X11DRV_FONT_InitX11Metrics(); if(X11DRV_XRender_Installed) text_caps |= TC_VA_ABLE; @@ -3324,7 +3325,7 @@ LOGFONT16 lf16; /* don't enumerate x11 fonts if we're using client side fonts */ - if (physDev->dc->gdiFont) return FALSE; +/* if (physDev->dc->gdiFont) return FALSE;*/ FONT_LogFontWTo16(plf, &lf16); ------------------------------------------------------------------------------- For information, here are the changes to xfont.c between April 3 and April 4 (attachment 3). diff -u -r --exclude=CVS 4_april_2002_mid/graphics/x11drv/xfont.c 4_april_2002/graphics/x11drv/xfont.c --- 4_april_2002_mid/graphics/x11drv/xfont.c Mon Apr 29 20:56:51 2002 +++ 4_april_2002/graphics/x11drv/xfont.c Sun Apr 28 20:53:50 2002 @@ -77,11 +77,6 @@ static fontAlias *aliasTable = NULL; -static UINT XTextCaps = (TC_OP_CHARACTER | TC_OP_STROKE | TC_CP_STROKE | TC_CR_ANY | - TC_SA_DOUBLE | TC_SA_INTEGER | TC_SA_CONTIN | - TC_UA_ABLE | TC_SO_ABLE | TC_RA_ABLE); - /* X11R6 adds TC_SF_X_YINDEP, maybe more... */ - static const char* INIFontMetrics = "cachedmetrics."; static const char* INIFontSection = "Software\\Wine\\Wine\\Config\\fonts"; static const char* INIAliasSection = "Alias"; @@ -952,7 +947,7 @@ aLFD.resolution_x = resx_string; strcpy(resy_string, resx_string); - if( uRelax == 0 && XTextCaps & TC_SF_X_YINDEP ) + if( uRelax == 0 && text_caps & TC_SF_X_YINDEP ) { if( fo->lf.lfWidth && !(fo->fo_flags & FO_SYNTH_WIDTH)) { @@ -2428,7 +2423,7 @@ fontInfo* pfi = pfm->pfi; /* device font to match */ LPLOGFONT16 plf = pfm->plf; /* wanted logical font */ UINT penalty = 0; - BOOL bR6 = pfm->flags & FO_MATCH_XYINDEP; /* from TextCaps */ + BOOL bR6 = pfm->flags & FO_MATCH_XYINDEP; /* from text_caps */ BOOL bScale = pfi->fi_flags & FI_SCALABLE; int d = 0, height; @@ -2834,24 +2829,22 @@ } /*********************************************************************** - * X11DRV_FONT_Init + * X11DRV_FONT_InitX11Metrics * * Initialize font resource list and allocate font cache. */ -int X11DRV_FONT_Init( int *log_pixels_x, int *log_pixels_y ) +void X11DRV_FONT_InitX11Metrics( void ) { char** x_pattern; unsigned x_checksum; - int i,res, x_count, fd, buf_size; + int i, x_count, fd, buf_size; char *buffer; HKEY hkey; - res = XFONT_GetPointResolution( log_pixels_x, log_pixels_y ); - + x_pattern = TSXListFonts(gdi_display, "*", MAX_FONTS, &x_count ); - TRACE("Font Mapper: initializing %i fonts [logical dpi=%i, default dpi=%i]\n", - x_count, res, DefResolution); + TRACE("Font Mapper: initializing %i x11 fonts\n", x_count); if (x_count == MAX_FONTS) MESSAGE("There may be more fonts available - try increasing the value of MAX_FONTS\n"); @@ -2917,7 +2910,7 @@ strcpy(buffer, "-*-*-*-*-normal-*-[12 0 0 12]-*-72-*-*-*-iso8859-1"); if( (x_fs = TSXLoadQueryFont(gdi_display, buffer)) ) { - XTextCaps |= TC_SF_X_YINDEP; + text_caps |= TC_SF_X_YINDEP; TSXFreeFont(gdi_display, x_fs); } } @@ -2939,11 +2932,20 @@ RAW_ASCENT = TSXInternAtom(gdi_display, "RAW_ASCENT", TRUE); RAW_DESCENT = TSXInternAtom(gdi_display, "RAW_DESCENT", TRUE); + return; +} + +/*********************************************************************** + * X11DRV_FONT_Init + */ +void X11DRV_FONT_Init( int *log_pixels_x, int *log_pixels_y ) +{ + XFONT_GetPointResolution( log_pixels_x, log_pixels_y ); if(X11DRV_XRender_Installed) - XTextCaps |= TC_VA_ABLE; + text_caps |= TC_VA_ABLE; - return XTextCaps; + return; } /********************************************************************** @@ -3016,7 +3018,7 @@ fm.plf = plf; fm.internal_charset = internal_charset; - if( XTextCaps & TC_SF_X_YINDEP ) fm.flags = FO_MATCH_XYINDEP; + if( text_caps & TC_SF_X_YINDEP ) fm.flags = FO_MATCH_XYINDEP; /* allocate new font cache entry */ @@ -3203,6 +3205,8 @@ EnterCriticalSection( &crtsc_fonts_X11 ); + if(fontList == NULL) X11DRV_FONT_InitX11Metrics(); + if( CHECK_PFONT(physDev->font) ) XFONT_ReleaseCacheEntry( __PFONT(physDev->font) ); @@ -3279,9 +3283,17 @@ ENUMLOGFONTEXW lf; NEWTEXTMETRICEXW tm; fontResource* pfr = fontList; - BOOL b, bRet = 0; + BOOL b, bRet = 0, using_gdi = 0; LOGFONT16 lf16; + DC *dc; + + dc = DC_GetDCPtr(hdc); + if(!dc) return FALSE; + if(dc->gdiFont) using_gdi = TRUE; + GDI_ReleaseObj(hdc); + /* don't enumerate x11 fonts if we're using client side fonts */ + if(using_gdi) return FALSE; FONT_LogFontWTo16(plf, &lf16);

1 0

Correct approach to deploy Wine applications
by Andriy Palamarchuk 03 May '02

03 May '02

I'm currently working on bug 585 - "wine installation process should install and configure wine applications". The first part of the work is done - wine applications, like regedit are installed by Wine build process. I wanted to ask you about correct approach to place these applications to deploy them. I think that applications can be called with full path, with or without extention, names in different cases. So I'm going to change wineinstall process to create symbolic links in c:/windows/system32 e.g. for regedit: regedit -> /usr/local/bin/wine regedit.so -> /usr/local/bin/regedit.so regedit.exe -> /usr/local/bin/wine regedit.exe.so -> /usr/local/bin/regedit.so This fixes problems with full path and with using or not using file extention, but how to handle case-insensitivity? Regedit can be called as REGEDIT, RegEdit, Regedit, regedit. Now multiply this on number of extentions exe, EXE. This is without considering really fancy cases, like "ReGeDiT". Is there a way to handle this problem? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

4 3

RE: wine/ ./winedefault.reg dlls/Makefile.in dlls/ ...
by Hidenori TAKESHIMA 03 May '02

03 May '02

I'm sorry, but I don't want to distribute my MultiMedia codes now... (I solicited Alexandre to remove my codes) Please don't use my removed code anymore... And I sent patches to removing from ReWind too, but is not applied yet now... Hidenori

4 6

known x11drv issue?
by Chris 03 May '02

03 May '02

hullo everybody, i'm new to the wine-devel list, but i was wondering if this: http://chris.luethy.net/wine/image.jpg was a known issue. Whenever you drag around flat-edged windows (I'm not sure what the offical name is in Win32), like the type you see in Winamp's preferences or any non-resizeable window (thus, the flat edge window) it leaves behind the white outline of that window (see link above). I was wondering if anybody is currently working to resolve this issue, or perhaps this is an issue in my configuration. Any hints? -- Chris Thielen chris(a)luethy.net

2 1

Re: wine/ ./winedefault.reg dlls/Makefile.in dlls/ ...
by Hidenori TAKESHIMA 03 May '02

03 May '02

> I haven't participated in the list before so I won't > now, but I'm curious. Is there some reason you are > taking all of your multimedia code out of the source > base? My all MultiMedia codes are completely written from scratch. No disassembling. I believe there are no legal issues. But, I cannot warrant... I should protect myself from any potential problems now... > Of course, someone else can just add it back in since > it was GPLd code... but if there is some good reason > not to add it back (patent infringement, etc.) you owe > it to the community to indicate that... derived > projects may already be dependent on your code. And > that would make it more likely that your wishes will > be carried out and no one will add the code back in. The main issues for me are 1) restrictions of EULA - some codes may be based on information from non-VS6. I don't want to battle with EULA. 2) afraid to many pending patents. I cannot check all patents... and there are some other reasons I don't want to write... So, finally, I decided to solicite Alexandre...

1 0

"Please report this"
by Medland, Bill 03 May '02

03 May '02

err:clipping:CLIPPING_UpdateGCRegion. hVisRgn is zero. Please report this. Duly reported. Anyone know why we cared? It's been in the code since the initial revision. Bill

2 1

Re: xrender patch
by Duane Clark 02 May '02

02 May '02

The xrender CVS patch of 4/23 is causing one of my apps to crash: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x438198ee). In 32-bit mode. Symbol h_errno is invalid Symbol __strtol_internal is invalid 0x438198ee (_end+0x2ce2726 in libXrender.so): movl 0x0(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x438198ee (_end+0x2ce2726 in libXrender.so) (ebp=405b60c4) 1 0x40af71cf (X11DRV_XRender_ExtTextOut+0x1103(physDev=0x40399e44, x=0x0, y=0x2c, flags=0x0, lprect=0x0, wstr=0x4039a6b0, count=0xc, lpDx=0x0) [xrender.c:703] in x11drv.dll.so) (ebp=405b650c) 2 0x40b0d92a (X11DRV_ExtTextOut+0x66(physDev=0x40399e44, x=0x0, y=0x20, flags=0x0, lprect=0x0, wstr=0x4039a6b0, count=0xc, lpDx=0x0) [text.c:65] in x11drv.dll.so) (ebp=405b6888) 3 0x407aa0a0 (ExtTextOutW+0x74(hdc=0x8f0, x=0x0, y=0x20, flags=0x0, lprect=0x0, str=0x4039a6b0, count=0xc, lpDx=0x0) [text.c:174] in libgdi32.dll.so) (ebp=405b68bc) 4 0x407a9ff0 (ExtTextOutA+0xc0(hdc=0x8f0, x=0x0, y=0x20, flags=0x0, lprect=0x0, str=0x43c85c40, count=0xc, lpDx=0x0) [text.c:155] in libgdi32.dll.so) (ebp=405b6900) 5 0x407aa11e (TextOutA+0x2a(hdc=0x8f0, x=0x0, y=0x20, str=0x43c85c40, count=0xc) [text.c:196] in libgdi32.dll.so) (ebp=405b692c) 6 0x00443f70 (schedit.exe..text+0x42f70 in C:\CapFast\wcs\bin\schedit.exe) (ebp=405b6948)

4 6

RE: More MSVC fixes
by Steven Edwards 02 May '02

02 May '02

How are you planning on linking the dlls/resources once wine is up 2 date on MSVC? Can MSVC build wrc resources and link them? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Re: wine/ ./winedefault.reg dlls/Makefile.in dlls/ ...
by Michael Cardenas 02 May '02

02 May '02

Who's Hidenori? Is this code being moved somewhere else? On Wed, May 01, 2002 at 08:29:19PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1020302959714181280302913 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 02/05/01 20:29:19 > > Modified files: > . : winedefault.reg > dlls : Makefile.in > dlls/avifil32 : Makefile.in avifil32.spec > dlls/imm32 : imm.c imm32.spec > dlls/quartz : Makefile.in main.c quartz.spec > include : Makefile.in > ole : uuid.c > Added files: > dlls/avifil32 : avifile.c > Removed files: > dlls/avifil32 : api.c avifile_private.h comentry.c iafile.c > iastream.c igframe.c main.c string.c > dlls/imm32 : immddk.h > dlls/quartz : README acmwrap.c amundoc.c asyncsrc.c > asyncsrc.h audioutl.c audioutl.h audren.c > audren.h avidec.c aviparse.c basefilt.c > basefilt.h basepin.c capgraph.c capgraph.h > complist.c complist.h csconv.c devenum.c > devenum.h enumunk.c enumunk.h fgevent.c > fgpass.c fgraph.c fgraph.h filesink.c > filesink.h fmap.c fmap.h ifgraph.c ijgdec.c > ijgdec.h imcntl.c imfilter.c impos.c imseek.c > iunk.c iunk.h memalloc.c memalloc.h midparse.c > mjpgdec.c mpadec.c mpgparse.c mpvdec.c mtype.c > mtype.h parser.c parser.h qtdec.c qtparse.c > quartz_private.h regsvr.c regsvr.h sample.c > sample.h seekpass.c seekpass.h sysclock.c > sysclock.h videoblt.c videoblt.h vidren.c > vidren.h wavparse.c xform.c xform.h > include : amaudio.h amvideo.h control.h errors.h evcode.h > strmif.h > > Log message: > Removed a bunch of multimedia code at Hidenori's request. > > Patch: http://cvs.winehq.com/patch.py?id=1020302959714181280302913 > > Revision Changes Path > 1.43 +0 -494 wine/winedefault.reg > 1.127 +4 -7 wine/dlls/Makefile.in > 1.17 +1 -8 wine/dlls/avifil32/Makefile.in > 1.9 +14 -16 wine/dlls/avifil32/avifil32.spec > 1.23 +17 -2 wine/dlls/avifil32/avifile.c > 1.15 +173 -784 wine/dlls/imm32/imm.c > 1.11 +16 -28 wine/dlls/imm32/imm32.spec > 1.22 +1 -46 wine/dlls/quartz/Makefile.in > 1.21 +1 -612 wine/dlls/quartz/main.c > 1.11 +8 -18 wine/dlls/quartz/quartz.spec > 1.47 +0 -6 wine/include/Makefile.in > 1.9 +2 -2 wine/ole/uuid.c > > > > -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

2 1

menu behaviour on window losing focus
by Rizsanyi Zsolt 02 May '02

02 May '02

Hi! Now that my patch to fix the alt behaviour made to the cvs (altough somewhat cleaned up by Alexandre :), I'm going on to fix what remained here to fix :) The problem is that when you activate the menu (by pressing ALT), and then the window loses focus, the menu stays active. And when you return to your window the menu still has focus. This is not right for two reasons: 1) This is not the windows behaviour - on windows when the window loses focus the menu is deactivated. I have tested this. The same is the behaviour with kde. 2) When you switch beetween windows by Alt+TAB sometimes the menu stays active. It does not happen so frequently, but it is annoying. So I would like to deactivate the menu when the window loses focus. Can somebody please point me to the point in code where I should put my deactivation (a code which is called on window deactivation), and also to the function by which I can deactivate the menu. If nobody answers, I will try to find these myself, but I have thought, that maybe there is somebody who can answer these questions in no time. Thanks in advance Zsolt Rizsanyi

2 1

a small error in Wine, when it gets to the make install stage..
by Ya'ad Golani 02 May '02

02 May '02

Good evening. When trying to install wine-20020411 I got the following error message (running through the "wineinstall" script, and not manually): --------------------------------------------------------------------------------- Performing 'make install' as root to install binaries, enter root password Password: /bin/bash: - : unrecognized option Either you entered an incorrect password or we failed to run 'make install' correctly. If you didn't enter an incorrect password then please report this error to wine-devel(a)winehq.com. --------------------------------------------------------------------------------- Welp, as you can see, I didn't enter the wrong password and got a "/bin/bash: - : unrecognized option", just letting you know. -Cheers, Ya'ad Golani.

2 1

DrawIconEx (...DI_IMAGE)
by Medland, Bill 02 May '02

02 May '02

Can anyone who understands the icon, bit stretch etc code help me out here? Our code calls DrawIconEx to draw an icon in the status bar, specifying DI_IMAGE rather than DI_NORMAL. On Windows the black pixels are drawn but on WINE they aren't. I have confirmed that it is the absence of the DI_MASK that results in this difference but I am not sure why. Is it obvious to someone more knowledgeable? Bill

1 0

PATCH - makedep
by Steven Edwards 02 May '02

02 May '02

I don't know if this will cause any problems for other platforms but it works here. Of course so did my last dirty hack so can someone point out a better way? According to http://www.delorie.com/djgpp/doc/libc/libc_95.html if the system has ftruncate it just calls it. If this isnt cool then would the configure check work here to #define ftruncate chsize? Changelog: changed ftruncate to chsize for mingw port cvs diff -u makedep.c Index: makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.10 diff -u -r1.10 makedep.c --- makedep.c 10 Mar 2002 00:24:22 -0000 1.10 +++ makedep.c 2 May 2002 09:31:04 -0000 @@ -381,7 +381,7 @@ { while (fgets( buffer, sizeof(buffer), file )) if (!strncmp( buffer, Separator, strlen(Separator) )) break; - ftruncate( fileno(file), ftell(file) ); + chsize( fileno(file), ftell(file) ); fseek( file, 0L, SEEK_END ); } if (!file)

2 1

Close X after one hour and half
by Marcelo Welter 02 May '02

02 May '02

Hello friends a run my applicationwith wine and xinit like: xinit wine myapp.exe -- :0 running very well, but after one hour and half this broken my X session and back to text console... i not see a messagem that refer to this problem in the screen and logs are equal I dont understand what happen with X to make... anybody help me..? Marcelo

1 0

Re: wine/ ./winedefault.reg dlls/Makefile.in dlls/ ...
by Andreas Mohr 02 May '02

02 May '02

On Wed, May 01, 2002 at 08:29:19PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1020302959714181280302913 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 02/05/01 20:29:19 > > Modified files: > . : winedefault.reg > dlls : Makefile.in > dlls/avifil32 : Makefile.in avifil32.spec > dlls/imm32 : imm.c imm32.spec > dlls/quartz : Makefile.in main.c quartz.spec > include : Makefile.in > ole : uuid.c > Added files: > dlls/avifil32 : avifile.c > Removed files: > dlls/avifil32 : api.c avifile_private.h comentry.c iafile.c > iastream.c igframe.c main.c string.c > dlls/imm32 : immddk.h > dlls/quartz : README acmwrap.c amundoc.c asyncsrc.c > asyncsrc.h audioutl.c audioutl.h audren.c > audren.h avidec.c aviparse.c basefilt.c > basefilt.h basepin.c capgraph.c capgraph.h > complist.c complist.h csconv.c devenum.c > devenum.h enumunk.c enumunk.h fgevent.c > fgpass.c fgraph.c fgraph.h filesink.c > filesink.h fmap.c fmap.h ifgraph.c ijgdec.c > ijgdec.h imcntl.c imfilter.c impos.c imseek.c > iunk.c iunk.h memalloc.c memalloc.h midparse.c > mjpgdec.c mpadec.c mpgparse.c mpvdec.c mtype.c > mtype.h parser.c parser.h qtdec.c qtparse.c > quartz_private.h regsvr.c regsvr.h sample.c > sample.h seekpass.c seekpass.h sysclock.c > sysclock.h videoblt.c videoblt.h vidren.c > vidren.h wavparse.c xform.c xform.h > include : amaudio.h amvideo.h control.h errors.h evcode.h > strmif.h > > Log message: > Removed a bunch of multimedia code at Hidenori's request. Whoa, this is certainly a "bunch" of code ! :-( I hope the reason for taking such rather drastic measures was important. Oh well, anyway, thanks for your contributions, Hidenori ! (I'm just assuming there are still some left ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

1 0

Ftruncate check
by Steven Edwards 01 May '02

01 May '02

I saw it was not applied. What was wrong with it? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 2

statusbar question
by Medland, Bill 01 May '02

01 May '02

I am about to have a go at tidying up a little problem with the statusbar and our application and I want to check as to what we really know and what we are currently guessing. Our application has a sunken owner-drawn part in the status bar, in which we draw multiple icons. Under WINE the part is not sunken (and the icons are poorly rendered - a separate issue) but the background colour is OK. I see that currently the code for statusbar is: For all parts If owner drawn then let the owner draw it else fill the background if ownerdrawn then let the owner draw it (legacy code) else draw the border if there is an icon then draw it draw the text. fi fi end for Can anyone justify this order as opposed to e.g. draw the background, draw the border, then if owner drawn let the owner draw the rest, otherwise draw the icon and text? It seems to me that the latter is more consistant with what I see but I don't want to break a load of stuff. Bill

1 0

Re: WM_PAINT BUG
by Dustin Navea 01 May '02

01 May '02

--- ziolas <ziolas11(a)poczta.onet.pl> wrote: > Well I've been trying to get UT and DeusEx to work > under winex 2.0 (yeah I > know about the linux binaries for UT). It both work > great under software > rendering but in HW they suck. In D3D the game loads > up, then complains about > vertex buffer and shuts down. In opengl it doesn't > display any 3d graphics > (ex. in deus ex I can see the menu, but not the 3d > logo behind it), and the > console is flooded with "beginpaint not called on > WM_PAINT" messages. This is > probably a bug which should be fixed. Good luck to > the winex devel's! > this message is probably better suited to the winex forums, but let me take a look at it and see whats up, be right back __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

1 0

MAX_PATH mess fix
by Steven Edwards 01 May '02

01 May '02

It seems mingw tries to include stdlib.h after windef.h in the build process and that was the result of the warnings/error. By making this change I don't have to change any of the other headers That depend on MAX_PATH (winnls,wingdi) by adding stdlib.h in them. I don't know if its right by the wine project standards but now I can compile 90% of the wine dll sources without warrnings/errors from stupid MAX_PATH. If someone has a better way please cvs diff -u me =) Thanks Steven Changelog: Fix the MAX_PATH mess under Mingw. (for real this time) cvs diff -u windef.h Index: windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.62 diff -u -r1.62 windef.h --- windef.h 10 Mar 2002 00:02:34 -0000 1.62 +++ windef.h 30 Apr 2002 21:41:42 -0000 @@ -149,6 +149,10 @@ #endif #endif /* NOMINMAX */ +#ifdef __MINGW__ +#include <stdlib.h> +#else + #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ #define _MAX_DRIVE 3 @@ -156,9 +160,13 @@ #define _MAX_DIR _MAX_FNAME #define _MAX_EXT _MAX_FNAME #define _MAX_PATH 260 -#endif +#endif /* _MAX_PATH */ + +#ifndef MAX_PATH #define MAX_PATH _MAX_PATH +#endif /* MAX_PATH */ +#endif /* __MINGW__ */ #define HFILE_ERROR ((HFILE)-1)

2 4

Java and Wine Interoperability on Solaris
by Warren_Baird＠cimmetry.com 01 May '02

01 May '02

Hi all, I've got an interesting problem on my hands - I need to invoke some winelib compiled win32 code from java (though jni) on a sparc-solaris box. Unfortunately I'm running into problems with the libthread.so library. If I create the JVM (which involves loading libthread.so) before wine, I get a segfault in the wine process_init function (during a call to getcwd that works its way down into libthread). If I instead initialize wine first, and then dlopen libthread.so and try to create the JVM, I get a segfault in the JVM code, in a function who's name includes the word thread (if that actually means anything). I've seen a few indications on the mailing list and in the docs that wine is not compatible with pthreads, but I haven't found a concrete discussion that gets into a lot of details - if anyone knows of a document somewhere that talks about this, I'd love to see it. I notice that there is a pthread.c file in scheduler, that seems to implement part of the pthreads api in terms of wine threads for glibc. Does anyone know if it would be possible to get something similar working on solaris? Does anyone have any other suggestions on how I might be able to make this work? Thanks! Warren

1 0

SetConsoleTitle
by Ann and Jason Edmeades 01 May '02

01 May '02

Question - I modified WCMD to support the 'TITLE' command which passed it through to SetConsoleTitle(A), and a simple program which subsequently calls GetConsoleTitle shows that the new value is in effect, but I dont see any window title for the WCMD shell. Is this a limitation of the console handling? (I tried with Managed='Y' and with no Managed line in my config file and the result was the same) Should I submit the patch to support the title command even though it will not be displayed currently? Its simple enough to do. Regards, Jason

1 0

word can't open documents...
by Michael Cardenas 01 May '02

01 May '02

With yesterday's cvs, opening a document causes it to crash with this output on the console: fixme:listview:LISTVIEW_UnsupportedStyles LVS_SHAREIMAGELISTS fixme:listview:LISTVIEW_SetItemCount flags LVSICF_NOINVALIDATEALL LVSICF_NOSCROLL not implemented fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial). fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x40552218, 0x4055263c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents", 0x00000001, 0x40553d68, 0x4055418c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x4055435c, 0x40554780): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x405532b0, 0x405536d4): stub X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 30392 Current serial number in output stream: 30395 -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

1 5

FW: argc/argv issue - More info, hack and questions...
by Ann and Jason Edmeades 01 May '02

01 May '02

Hi, I havent had any replies to the attached issue I was debugging - Can anyone assist, or should I just submit the patch. I know the patch works but I feel it is just masking a compatibility problem between two of the wine internal routines. Jason -----Original Message----- Hello, I am still investigating this argv/argc issue. The sequence of events as far as I can tell: CreateProcessA(NULL, "regsvr32 comdlg32.ocx",....) Process_CREATE calls fork_and_exec( NULL, "regsvr32 comdlg32.ocx", ...) This sees there is no explicitly specified filename so inserts wine and -- into the command line (now "wine -- regsvr32 comdlg32.ocx") Eventually the new process starts with the wine -- regsvr32 comdlg32.ocx as the command line, so it needs to strip off the inserted fields, and in PROCESS_InitWine, main_exe_name is correct (path\regsvr32.exe) but the argc/argv includes these new fields. At the top it states: (Scheduler/process.c, lines 491/492): app_argv++; /* remove argv[0] (wine itself) */ app_argc--; This obviously leaves behine the -- and things go downhill from there onwards. Interestingly wine -- regsvr32 comdlg32.ocx works fine, so there must be command line processing here which doesnt occur during the CreateProcess route. Question: Should fork_and_exec insert the -- into the command line? If it should, should PROCESS_InitWine check for it, ie: app_argv++; /* remove argv[0] (wine itself) */ app_argc--; if (app_argc && strcmp(app_argv[0], "--") == 0) { app_argv++; /* remove argv[1] ('--' inserted by fork_and_exec) */ app_argc--; } However, what implications are of doing this (it works, of course). This feels like hacking around an imcompatibility within wine but I am happy to submit a patch as it definitely resolves a problem for me. Regards, Jason

3 3

Jump to page:

2025

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