wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Fun Projects on Slashdot
by Dimitrie O. Paun 18 Nov '02

18 Nov '02

Hehe, It's hard to keep these things 'secret' :))) http://developers.slashdot.org/developers/02/11/17/1648220.shtml?tid=125 -- Dimi.

3 3

wine-devel@winehq.com
by Mark Hannessen 18 Nov '02

18 Nov '02

> I know I sound like a broken record, but just so it's out there: > Visual Foxpro 5 and 6 IDE's DO run under Wine, BUT, left mouse clicks in > child windows are broken. I've compiled and run VFP apps under wine, > but it's a pain in the butt to go kybd only in a Visual IDE :P are you volontairing ? > Sorry not to answer your main questions, but some ideas on this ... > We use gcc, wxWindows and mingw. Not sure how much you _need_ .NET > but we migrated our (fairly complex) app from Visual C++/MFC to wxWindows > and it was definitely worth it. Also we can use gcc to cross-compile > from Linux for Windows, so basically although our software is currently used > exclusively on Windows, I can develop it all on Linux (obviously some > testing to be done on Windows as well, but basically it works). And it's all > free, open-source software. I'd recommend checking it out. this combined with mono might give you just enough to develop .NET progs under linux. Mark Hannessen

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> On Mon, Nov 18, 2002 at 04:21:37PM +0100, Patrik Stridvall wrote: > > > Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit : > > > > > Corrects this line in winapi_check: > > > > > win32/device.c:544: kernel32: void > > > VxDCall(DWORD,CONTEXT86 *): calling > > > > > convention mismatch: cdecl != stdcall > > > > > > > > I'm not 100% sure this really is a bug. > > > > Don't trust winapi_check too much it is very ad hoc. :-) > > > > > > > > It might however be a bug but I never got around to test it > > > properly. > > > > > > > > So, have you verified that this really is correct? > > > > > > Well, kernel32.spec references them by "stdcall -register -i386". > > > Another API referenced the same way is CommonUnimpStub, and > > > in thunk.c, > > > it is declared as "void WINAPI". > > > > > > Is it sufficient checking? > > > > I'm not sure, it might be the other API(s) that are wrong > > or that VxDCall is a special case. That why I haven't dared > > changed anything. > > I think it needs to be WINAPI, the __wine_call_from_32_regs > assembler thunk > does not remove arguments from stack. Yes, I'm leaning in that direction as well the more I think about it. However, I don't think it is enough. It will work for the implemented VxDCall that pops the stack itself, however it will not work for unimplemented VxDCalls since they will not clean up the stack correctly AFAICS. Anyway, if so it has been wrong a long time (so long that I don't notice the warning from winapi_check any longer :-), so I wonder why it wasn't noticed by anybody else running an application using VxD calls.

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit : > > > Corrects this line in winapi_check: > > > win32/device.c:544: kernel32: void > VxDCall(DWORD,CONTEXT86 *): calling > > > convention mismatch: cdecl != stdcall > > > > I'm not 100% sure this really is a bug. > > Don't trust winapi_check too much it is very ad hoc. :-) > > > > It might however be a bug but I never got around to test it > properly. > > > > So, have you verified that this really is correct? > > Well, kernel32.spec references them by "stdcall -register -i386". > Another API referenced the same way is CommonUnimpStub, and > in thunk.c, > it is declared as "void WINAPI". > > Is it sufficient checking? I'm not sure, it might be the other API(s) that are wrong or that VxDCall is a special case. That why I haven't dared changed anything. The problem with VxDCall is that is have multiple entries under different external names. ./dlls/kernel/kernel32.spec: 1 stdcall -register -i386 VxDCall0(long) VxDCall ./dlls/kernel/kernel32.spec: 2 stdcall -register -i386 VxDCall1(long) VxDCall ./dlls/kernel/kernel32.spec: 3 stdcall -register -i386 VxDCall2(long) VxDCall ./dlls/kernel/kernel32.spec: 4 stdcall -register -i386 VxDCall3(long) VxDCall ./dlls/kernel/kernel32.spec: 5 stdcall -register -i386 VxDCall4(long) VxDCall /dlls/kernel/kernel32.spec: 6 stdcall -register -i386 VxDCall5(long) VxDCall ./dlls/kernel/kernel32.spec: 7 stdcall -register -i386 VxDCall6(long) VxDCall ./dlls/kernel/kernel32.spec: 8 stdcall -register -i386 VxDCall7(long) VxDCall ./dlls/kernel/kernel32.spec: 9 stdcall -register -i386 VxDCall8(long) VxDCall Searching on the Internet reveals this page: http://www.mbs.spb.ru/kb/w32mbr.htm According to this page VxDCall[0-8] really should be stdcall. ---8<--- /* Kernel32 W32-caller prototypes */ DWORD WINAPI VxDCall0(DWORD service); DWORD WINAPI VxDCall1(DWORD service, DWORD); DWORD WINAPI VxDCall2(DWORD service, DWORD, DWORD); DWORD WINAPI VxDCall3(DWORD service, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall4(DWORD service, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall5(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall6(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall7(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); DWORD WINAPI VxDCall8(DWORD service, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD, DWORD); ---8<--- and this ---8<--- vxdcall.def LIBRARY KERNEL32 EXPORTS VxDCall0@0 @1 VxDCall1@8 @2 VxDCall2@12 @3 VxDCall3@16 @4 VxDCall4@20 @5 VxDCall5@24 @6 VxDCall6@28 @7 VxDCall7@32 @8 VxDCall8@36 @9 ---8<--- However something with VxDCall is wrong nether the less. WINAPI functions (read: __stdcall) functions expects that the callee cleans up the argument stack and the number of arguments is different depending on which function is called. Looking at VxDCall (and what it calls) in win32/device.c I see that the implemented VxDCall pops the stack. However the unimplemented VxDCalls doesn't even though they might have gotten some arguments. This means AFAICS that VxDCall corrupts the stack in such cases... So I'm pretty convinced that something is wrong however I don't think you patch is the solution to the problem. It might possible be part of a solution though... Any suggestions?

2 1

RE: vxdcall calling convention
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Corrects this line in winapi_check: > win32/device.c:544: kernel32: void VxDCall(DWORD,CONTEXT86 *): calling > convention mismatch: cdecl != stdcall I'm not 100% sure this really is a bug. Don't trust winapi_check too much it is very ad hoc. :-) It might however be a bug but I never got around to test it properly. So, have you verified that this really is correct?

2 1

RE: Nameless struct problem
by Patrik Stridvall 18 Nov '02

18 Nov '02

> Dimitrie O. Paun wrote: > > >I had to use the following hack to allow this > >bit to go through my g++ compiler. > > > >I'm using RedHat 8.0, so this gives me: > > > >[dimi@dimi wine.src]$ g++ --version > >g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > >Copyright (C) 2002 Free Software Foundation, Inc. > >This is free software; see the source for copying > conditions. There is NO > >warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > > Glad you included the warranty bit :-) > > > > >Any ideas what's wrong here, and how it can be fixed? > > > > > Not particularly, but I know I've seen other examples of g++ > being more > strict / particular > about structs than gcc. What error do you get? You could try > -E for the > preprocessor > output and search through it for DUMMYSTRUCTNAME ; it could > be being defined > earlier on or somewhere else in a way that confuses it here... DUMMYSTRUCT is defined as nothing if the compiler supports nameless structs. GNU C++ was mistakenly believed by me to support nameless structs. I didn't check however, I have check now and it seem like no version of GNU C++ does. :-( Not that it really needs to support it since you could get the same effect with "dummy" structs/classes and inheritence, but then I really can't see any particular reason not to support it since makes at least as much sense (if not more) in C++ to have unnamed structs as in C... Anyway, there is a patch in wine-patches that fixes the problem and since it as I said is always possible to "fake it" in C++ there is no great need to ask the GNU C++ developers the fix the problem either...

1 0

Re: Wine with .NET?
by Mark Hannessen 18 Nov '02

18 Nov '02

> Ladies and Gentlemen, > > I am a Microsoft developer and currently pushing the capabilities of the > .NET Framework. On that same note, I am considering moving my laptop to > some version of Linux (either Solaris v8.0 or Red Hat). I assumed that > I would need to use VMWare or some equivalent to continue using Visual > Studio .NET. Can anyone give me some advice? > > Many thanx, > Fred Lackey > Orlando, Florida have you already tryd wine to run visual studio .NET ? in theory it is possible but i don't think anyone has ever tryd. ( and it will likely not work yet, feel free to send patches ) if you want to port visual studio .NET to linux using wine you should use winemaker. Mark Hannessen

7 8

Patch for bug 1150
by Andrew John Hughes 18 Nov '02

18 Nov '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch should resolve bug 1150, compiling commdlg with -DSTRICT. Hope this is okay - this is my first time hacking on Wine. The patch is also attached to the bug. - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE92DtTSE/kMce1ABARAgXdAJ0RKUv3appMGjMo1+TgyhyujuMzGwCdHhNc dYlWgrnc+lCHhrdfM2cwYXY= =hum9 -----END PGP SIGNATURE-----

1 0

RE: Nameless struct problem
by Patrik Stridvall 17 Nov '02

17 Nov '02

> I had to use the following hack to allow this > bit to go through my g++ compiler. > > I'm using RedHat 8.0, so this gives me: > > [dimi@dimi wine.src]$ g++ --version > g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > Any ideas what's wrong here, and how it can be fixed? Yes, it seems that GNU C++ 3.2 (unlike GNU C 3.2) doesn't support unnamed structs. Strange. Not that it really matters that much because you could do "magic" with inheritance in C++. See below. > Index: include/winuser.h > =================================================================== > RCS file: /var/cvs/wine/include/winuser.h,v > retrieving revision 1.152 > diff -u -r1.152 winuser.h > --- include/winuser.h 4 Nov 2002 22:47:59 -0000 1.152 > +++ include/winuser.h 17 Nov 2002 01:32:56 -0000 > @@ -2387,13 +2387,13 @@ > > typedef struct tagMONITORINFOEXA > { > - MONITORINFO DUMMYSTRUCTNAME; > + MONITORINFO DUMMYSTRUCTNAMEx; > CHAR szDevice[CCHDEVICENAME]; > } MONITORINFOEXA, *LPMONITORINFOEXA; > > typedef struct tagMONITORINFOEXW > { > - MONITORINFO DUMMYSTRUCTNAME; > + MONITORINFO DUMMYSTRUCTNAMEx; > WCHAR szDevice[CCHDEVICENAME]; > } MONITORINFOEXW, *LPMONITORINFOEXW; This uses inheritance with C++ in the Microsoft SDK. Working on patch. Coming very soon.

1 0

Nameless struct problem
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

I had to use the following hack to allow this bit to go through my g++ compiler. I'm using RedHat 8.0, so this gives me: [dimi@dimi wine.src]$ g++ --version g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any ideas what's wrong here, and how it can be fixed? Index: include/winuser.h =================================================================== RCS file: /var/cvs/wine/include/winuser.h,v retrieving revision 1.152 diff -u -r1.152 winuser.h --- include/winuser.h 4 Nov 2002 22:47:59 -0000 1.152 +++ include/winuser.h 17 Nov 2002 01:32:56 -0000 @@ -2387,13 +2387,13 @@ typedef struct tagMONITORINFOEXA { - MONITORINFO DUMMYSTRUCTNAME; + MONITORINFO DUMMYSTRUCTNAMEx; CHAR szDevice[CCHDEVICENAME]; } MONITORINFOEXA, *LPMONITORINFOEXA; typedef struct tagMONITORINFOEXW { - MONITORINFO DUMMYSTRUCTNAME; + MONITORINFO DUMMYSTRUCTNAMEx; WCHAR szDevice[CCHDEVICENAME]; } MONITORINFOEXW, *LPMONITORINFOEXW; -- Dimi.

2 1

Problem running Anstoss2 under Wine
by Adrian Bunk 17 Nov '02

17 Nov '02

I'm trying to run Anstoss2 (a five years old German soccer simulation - I'm only interested in the strategic part of the game) under Wine. I tried the Debian package of the 20021031 Release and a self-compiled package of a 20021116 CVS snapshot. The following messages occur during the start of the game: <-- snip --> $ wine anstoss2.exe fixme:file:DEVICE_Open Unknown/unsupported VxD SICE. Try setting Windows version to 'nt40' or 'win31'. fixme:file:DEVICE_Open Unknown/unsupported VxD NTICE. Try setting Windows version to 'nt40' or 'win31'. err:ntdll:RtlpWaitForCriticalSection section 0x400f10bc "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=081b1ce0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403a7528)->(00010024,00000008) fixme:ddraw:Main_DirectDrawClipper_Initialize (0x403a7e38)->(0x403a7534,0x00000000),stub! err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 10026! err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 10026! err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 10026! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403a7428)->(0002002d,00000008) fixme:ddraw:Main_DirectDrawClipper_Initialize (0x403ae128)->(0x403a7434,0x00000000),stub! fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle right now. <-- snip --> The "DEVICE_Open" messages might be related to the copy protection (?). At the beginning I see a small "Cannot open file" window [1] that seems to be non-fatal. The screenshot at [2] shows the main problem I observe: Something with the left-right justification of elements doesn't work. There are three checkbuttons and the one besides "Neues Spiel beginnen" is selected and that's the place where you can select it - but the background black circles that should indicate where you are able to click are 2cm left and a bit ahead of the correct location. The smiling ball at the right bottom is the place to click when you are finished with this page - but it's outside the rest, the thing that is painted in the two light blue colors (e.g. the "ADY" at the left bottom) is the background picture of my window manager. If there's any other information that might help simply ask. TIA Adrian [1] http://www.fs.tum.de/~bunk/TMP/cannot-open-file.png [2] http://www.fs.tum.de/~bunk/TMP/anstoss2-start.png -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed

1 0

Re: some ismbc* functions: third try
by Dmitry Timoshkov 17 Nov '02

17 Nov '02

"Greg Turner" <gmturner007(a)ameritech.net> wrote: > totally untested, but it does compile, and seems logical > enough. while i was at it, i added a few more. Probably it would be better to create a common internal function which accepts C1_???? flags, does all remaining common operations with converting character(s) to unicode and returns (ctype & flags) != 0? -- Dmitry.

2 1

Re: FAQ in sgml format
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

On November 15, 2002 09:19 pm, Tony Lambregts wrote: > Here is the FAQ in sgml format with some very minor additions from the > html version by Dimitrie O. Paun, Keith Matthews and Thomas Wickline Can you please send me a copy of the file you used to generate the SGML, so I can track changes? TIA. -- Dimi.

2 1

Visual-MingW
by Dimitrie O. Paun 17 Nov '02

17 Nov '02

Just a quick heads up. I've been working on compiling Visual-MingW as a Winelib app. Hence the header patches I've sent :) I got it to compile (including resources), but it does not link. Shouldn't be too hard to do, I'll post what changes I had to do later on. -- Dimi.

1 0

RE: Wine with .NET?
by Fredrick P. Lackey 16 Nov '02

16 Nov '02

By the way, I would PREFER to use Wine and NOT VMWare. I guess I should have mentioned that. Thanx, Fred > -----Original Message----- > From: Fredrick P. Lackey > [mailto:fred.lackey@marbellasoftware.com] > Sent: Saturday, November 16, 2002 1:43 PM > To: 'wine-devel(a)winehq.com' > Subject: Wine with .NET? > Importance: High > > Ladies and Gentlemen, > > I am a Microsoft developer and currently pushing the capabilities of > the .NET Framework. On that same note, I am considering moving my > laptop to some version of Linux (either Solaris v8.0 or Red Hat). I > assumed that I would need to use VMWare or some equivalent to continue > using Visual Studio .NET. Can anyone give me some advice? > > Many thanx, > Fred Lackey > Orlando, Florida

2 1

CoInitialize
by steve.lustbader＠philips.com 16 Nov '02

16 Nov '02

One of the threads in my app calls CoInitialize, expecting it to return S_OK (in fact, it's followed by an assert statement requiring that it returns S_OK). When I run it in Wine, however, CoInitialize returns S_FALSE, implying that this thread has already initialized the COM library. Other threads call CoInitialize, but this is the first time that this thread calls it. Does Wine initialize COM differently from Windows? Are the other threads' calls to CoInitialize screwing up this thread's call? -Steve

3 2

Wine and iexplore.exe
by Luca Rosellini 16 Nov '02

16 Nov '02

Hello, I successfully run Internet Explorer 5.00 from a win98SE partition. It works smoothly on almost all sites even with those sites that use flash. Today I tryed to login to my cisco.netacad.net account using emulated wine and I had this error: fixme:file:DeviceIo_MMDEVLDR (5,(nil),0,0x483e610c,4,0x406d0268,(nil)): stub and then: err:mmsys:MMDRV_Alloc Too many open drivers I am using Wine 20021007 under slackware 8.1. Regards -- Luca Rosellini Email: luca.rosellini(a)libero.it Fax: +391786006032 PGP FP: 7711 92E2 30D2 A731 4362 4A7B 748C DF72 FE63 1C40 Registered Linux User 261056

1 0

Wine with .NET?
by Fredrick P. Lackey 16 Nov '02

16 Nov '02

Ladies and Gentlemen, I am a Microsoft developer and currently pushing the capabilities of the .NET Framework. On that same note, I am considering moving my laptop to some version of Linux (either Solaris v8.0 or Red Hat). I assumed that I would need to use VMWare or some equivalent to continue using Visual Studio .NET. Can anyone give me some advice? Many thanx, Fred Lackey Orlando, Florida

1 0

Re: Resend: implement _ismbcalpha, _ismbcalnum
by Dmitry Timoshkov 16 Nov '02

16 Nov '02

"Greg Turner" <gmturner007(a)ameritech.net> wrote: > +int _ismbcalpha(unsigned int ch) > +{ > + if (ch < 0x100) > + return ((0x41 <= ch && ch <= 0x5a) || > + (0x61 <= ch && ch <= 0x7a) || > + /* Japanese/Katakana, CP 932 */ > + (0xa6 <= ch && ch <= 0xdf)); > + else > + { > + FIXME("Handle MBC chars\n"); > + return 0; > + } > +} It's better to create a correct multibyte character pair and call GetStringType then. -- Dmitry.

3 7

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall 16 Nov '02

16 Nov '02

> On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > > Now that we have the permission to use cabextract > > under the LGPL it would be useful to have stubs > > for CABINET.DLL so intrested people can work > > with implementing it with fewer "infrastructure" > > problems. [snip] > Anyone working on this? If not I'd be glad to take it on, > seems like it > should be easy. I personally doesn't currently have that much time to work with it. However, when I saw that not much happend despite getting code from cabextrect under LGPL I thought that perhaps people were having trouble on how to create a new DLL in Wine and how to extract the declarations from the Microsoft header without creating a derived work. I have done it many times before so thought why not do it... So I very happy that somebody is intrested in continuing. PS. If anybody have some other DLL that they wish to implement but don't now how to do it, don't hesitate to ask me to create a stub DLL with related headers.

2 1

Font selection - please review
by Shachar Shemesh 16 Nov '02

16 Nov '02

Hi all, I am thinking of submitting the attached patch. The problem is that I am not comfertable with the location I added it. As far as I could tell, there is nowhere in the whole of Wine where the selected language is matched with the charset to be used by default. This is what this patch comes to amend. There is a slight awkwardness that is inherent to the Win32 API, in which, in order to create the default font, you zero out a LOGFONT struct, fill in the struct length, and call "CreateFontIndirect". Looking at the resulting struct, however, reveals that what you have just asked for is a ANSI_CHARSET font. It appears that windows correctly understands that this is an uninitialized LOGFONT, apparently based on the fields tested. The reason I am not sure this is the correct place, however, is that there seem to be system-wide default fonts, and I'm not 100% sure why, but they are ANSI (read - latin) only. I am willing to delve deeper into that part of the code, but I need to understand it better first. I was wondering whether anyone else on this list is aware of the reasons. Shachar License: LGPL Changelog: Shachar Shemesh <winecode(a)sun.consumer.org.il> objects/font.c * Added a function to convert language to charset. * Added code to select the apropriate charset in case the charset was not specified (DEFAULT_CHARSET or uninitialized LOGFONT). Index: objects/font.c =================================================================== RCS file: /home/sun/sources/cvs/wine/objects/font.c,v retrieving revision 1.89 diff -u -r1.89 font.c --- objects/font.c 13 Nov 2002 04:13:42 -0000 1.89 +++ objects/font.c 14 Nov 2002 19:49:44 -0000 @@ -41,6 +41,8 @@ static INT FONT_GetObjectW( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); static BOOL FONT_DeleteObject( HGDIOBJ handle, void *obj ); +static BYTE FONT_GetCharsetFromLang( LANGID language ); + static const struct gdi_obj_funcs font_funcs = { FONT_SelectObject, /* pSelectObject */ @@ -317,6 +319,16 @@ { memcpy( &fontPtr->logfont, plf, sizeof(LOGFONTW) ); + /* Make sure the correct font is chosen in case the decision is up to us */ + if( plf->lfCharSet==DEFAULT_CHARSET || + (plf->lfHeight==0 && plf->lfWidth==0 && plf->lfEscapement==0 && + plf->lfCharSet==0 && plf->lfPitchAndFamily==0 && + plf->lfFaceName[0]==0) ) + { + fontPtr->logfont.lfCharSet= + FONT_GetCharsetFromLang( LANGIDFROMLCID(GetUserDefaultLCID())); + } + TRACE("(%ld %ld %ld %ld %x) %s %s %s => %04x\n", plf->lfHeight, plf->lfWidth, plf->lfEscapement, plf->lfOrientation, @@ -2207,4 +2219,69 @@ BOOL WINAPI RemoveFontResourceExW( LPCWSTR str, DWORD fl, PVOID pdv ) { return WineEngRemoveFontResourceEx(str, fl, pdv); +} + +/*********************************************************************** + * FONT_GetCharsetFromLang + */ +static BYTE FONT_GetCharsetFromLang( LANGID language ) +{ + switch( PRIMARYLANGID(language) ) + { + /* I am currently unaware of any language that requires SYMBOL + case : + return SYMBOL_CHARSET;*/ + case LANG_JAPANESE: + return SHIFTJIS_CHARSET; + case LANG_KOREAN: + return HANGEUL_CHARSET; + case LANG_CHINESE: + { + switch( SUBLANGID(language) ) + { + case SUBLANG_CHINESE_SIMPLIFIED: + return GB2312_CHARSET; + case SUBLANG_CHINESE_TRADITIONAL: + return CHINESEBIG5_CHARSET; + } + } + case LANG_GREEK: + return GREEK_CHARSET; + case LANG_TURKISH: + return TURKISH_CHARSET; + case LANG_HEBREW: + return HEBREW_CHARSET; + case LANG_ARABIC: + return ARABIC_CHARSET; + case LANG_LATVIAN: + return BALTIC_CHARSET; + case LANG_VIETNAMESE: + return VIETNAMESE_CHARSET; + case LANG_RUSSIAN: + case LANG_BULGARIAN: + /* Byelorussian probably goes under SUBLANG_RUSSIAN_MOLDAVIA */ + case LANG_MACEDONIAN: + case LANG_SERBIAN: + case LANG_UKRAINIAN: + return RUSSIAN_CHARSET; + case LANG_CZECH: + case LANG_HUNGARIAN: + case LANG_POLISH: + case LANG_ROMANIAN: + /* For some reason SERBIAN and CROATIAN has the same value, despite + * seeming to require different encodings. I disabled one at random. + case LANG_CROATIAN: */ + case LANG_SLOVAK: + case LANG_SLOVENIAN: + case LANG_SORBIAN: + return EE_CHARSET; + case LANG_THAI: + return THAI_CHARSET; + /* The JOHAB charset seem to require KOREAN as well. I don't know when + * to use that instead + case LANG_KOREAN: + return JOHAB_CHARSET; */ + } + + return ANSI_CHARSET; }

2 2

kdelnk2desktop.py
by Dustin Navea 16 Nov '02

16 Nov '02

I just switched to slackware from Mandrake8 and I was foolin around tryin to see if ther ewas an xchat built with kdelibs and stumbled across kdelnk2desktop.py in my /usr/bin dir. im not sure if it exists in other distors but it could be a replacement for the current wineshelllink on distros that do have it. Anyone wanna look into this or want me to, let me know. -Dustin

2 1

something about Chinese character processing
by yf 16 Nov '02

16 Nov '02

I found that to show Chinese character properly, following should be modified. But it only affect menu, the character within the windows still as before ( can't be showed properly). What should I do then? --- wine-20021031/graphics/x11drv/codepage.c.original 2002-11-16 13:50:31.000000000 +0800 +++ wine-20021031/graphics/x11drv/codepage.c 2002-11-04 17:44:14.000000000 +0800 @@ -279,8 +279,8 @@ { if ( IsLegalDBCSChar_cp936( *str_src, *(str_src+1) ) ) { - str2b_dst->byte1 = *str_src; - str2b_dst->byte2 = *(str_src+1); + str2b_dst->byte1 = *str_src&0x7f; + str2b_dst->byte2 = *(str_src+1)&0x7f; str_src++; } else

2 1

Re: StgIsStorageFile Try #2
by Dmitry Timoshkov 16 Nov '02

16 Nov '02

"Ryan Cumming" <ryan(a)completely.kicks-ass.org> wrote: > + strW = HEAP_strdupAtoW( GetProcessHeap(), 0, fn ); Please don't use HEAP_strdupAtoW. Use RtlCreateUnicodeStringFromAsciiz instead. -- Dmitry.

1 0

wineoss MIDI help
by Jeff Smith 16 Nov '02

16 Nov '02

I have several programs that require MIDI support. When I try to run them I get: err:midi:OSS_MidiInit ioctl on midi info for device 0 failed. This comes from line 274 of dlls/winmm/wineoss/midi.c When this error is encountered, the /dev/sequencer is closed and OSS_MidiInit returns. I have determined that my card indicates having two midi devices. Only the second supports the SNDCTL_MIDI_INFO ioctl. But midi.c never gets to the second because of the first. I have tried some simple hacks, but have not accomplished anything notable. Anybody got any insights as to a simple fix? If not, would I be better off delving into wineoss or getting the first MIDI device of the emu10k1 driver to handle MIDI_INFO? ;-) -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

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