March 2006 - Wine-Devel - list.winehq.org

Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Hi all. About half a year ago I replaced my old desktop by an AMD64 box and my previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib LFS. And since then I'm not able to run any DirectX title anymore that used to work before. This is the way I usually compile wine (GCC 3.4.4): ./configure --prefix=/opt/wine-CVS20060307 \ --x-libraries=/usr/X11R6/lib && make depend && make && su -c "make install" Here are some games that used to work on my old LFS, their behaviour and the error messages. I've also attached a short log of each game to this messages. All these logs have been recorded with the CVS version of wine from 2006/03/05. Age of Empires 2 starts up, I can hear sound. When I click on "Single Player", the game hangs with the following message: err:seh:setup_exception stack overflow 24 bytes in thread 0009 eip 55726262 esp 55ca0fe8 stack 0x55ca1000-0x55db0000 Backgammon Pro is an older (7 years or so) backgammon game, quite simple and 2D, but uses DirectDraw. It crashes at startup: err:ntdll:RtlpWaitForCriticalSection section 0x5574d040 "directory.c: dir_section" wait timed out in thread 000b, blocked by 000c, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 Diablo 2 VidTest (D2VidTest.exe) runs fine and suggests Direct3D for rendering. When I click on the ok-button to quit, it keeps hanging: err:ntdll:RtlpWaitForCriticalSection section 0x6ffa0730 "?" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Diablo 2 crashes at startup after some time: err:ntdll:RtlpWaitForCriticalSection section 0x5574d6c0 "virtual.c: csVirtual" wait timed out in thread 0010, blocked by 0000, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 Half-Life crashes at startup: err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 Monkey Island 4 (OpenGL-mode) crashes at startup: err:seh:setup_exception stack overflow 240 bytes in thread 0009 eip 557013e6 esp 55ca0f10 stack 0x55ca1000-0x55db0000 StarCraft starts to the title menu, but clicking on "Single Player" crashes it: err:seh:setup_exception stack overflow 276 bytes in thread 0009 eip 557013e6 esp 55ca0eec stack 0x55ca1000-0x55db0000 WarCraft 3 (OpenGL-mode) doesn't show up anything, just hangs silently. As you can see, the most common errors are err:seh:setup_exception and err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests with other games like Revolt, Anno 1503, Half-Life 2, and the errors all look alike. I have tried the following things to solve the problem: * Deleted my ~/.wine, over and over again ;-) * Compiled wine without any optimization flags * Compiled wine on a x86 Debian box and copied the installation over * Copied my ~/.wine to that Debian box, where most of the games run fine * Tried different wine versions, starting with pre-0.9 versions, ending with the latest CVS version * Used winetools to setup an environment with many native DLLs. Installation of most of the software including IE worked fine, but did not help though. * Searched this mailing list archive and the web for similar errors Something is definitely going wrong with this. Anybody an idea? I would appreciate any help. Cheers, Christian Schneider

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

H. Verbeet schrieb: > On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: >> This doesn't really make sense to me - the point of unspecified behavior >> if a parameter is NULL would be to speed up the function under contract >> with the caller. If you're already doing the check, why not handle it in >> some way other than crashing? > Because we *want* to crash and get a nice backtrace. hm maybe I'm missing something but afaik you will get a backtrace right back into the application code, which will help you exactly nothing (unless you have the source code of the game and the binary doesn't have its debugging information stripped which is very likely not the case). So you have to figure out where you might have returned something wrong by looking at the traces from _before_ GetCreationParameters. The backtrace itself won't give you _any_ clues. Unless some app relies on this crashing behaviour(which I doubt), I don't think wine should implement bugs just because MS does it. Seems a bit obscure strategy to me to crash in case of an error instead of proper error checking/reporting.

March 7, 2006

Re: valgrinding mozilla on wine

by Dan Kegel

On 3/7/06, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > - the good news: most of the points related to false positives is either > in latest Wine and will be present in yet to come 3.1.1 (RC1 is for > Friday this week) > > - the bad news: the SEH support is still deficient, and we still have > stack issues (what you get). I updated the VG patch on the Wiki that > fixes (for me) some errors that look very close to what you describe > (the stack ones). OK. I'll try your new patch when 3.1.1 rc1 comes out. > As of today, the VG folks are rather sluggish to look > at those issues and to integrate some of the patches. So, they won't be > present for 3.1.1, perhaps for 3.2 (somewhere in April). That's still more responsive than a lot of projects. Thanks for moving this along! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Re: valgrinding mozilla on wine

by Eric Pouech

Dan Kegel wrote: > On 3/7/06, Dan Kegel <dank(a)kegel.com> wrote: > >>I'm trying to track down a wine crash in firefox >>(http://bugs.winehq.org/show_bug.cgi?id=4762) >>and thought valgrind might be helpful. So, following >>http://wiki.winehq.org/Wine_and_Valgrind > > > When I posted the above, I hadn't yet applied the patch > mentioned in the wiki page. When I did, valgrind itself > crapped out: > > ==18736== Warning: client switching stacks? SP change: 0xBE857B4C --> 0x48DFFF0 > ==18736== to suppress, use: --max-stackframe=1174963364 or greater > --18707-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting > --18707-- si_code=1; Faulting address: 0x57E58959; sp: 0x62527DA4 > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==18707== at 0xB001AB5C: vgPlain_get_StackTrace2 (m_stacktrace.c:147) > ==18707== by 0xB001AC31: vgPlain_get_StackTrace (m_stacktrace.c:331) > ==18707== by 0xB000DDCF: vgPlain_record_ExeContext (m_execontext.c:199) > ==18707== by 0xB0001116: create_MAC_Chunk (mac_malloc_wrappers.c:139) > ==18707== by 0xB0001B17: vgMAC_malloc (mac_malloc_wrappers.c:203) > ==18707== by 0xB002D9C3: do_client_request (scheduler.c:987) > ==18707== by 0xB002D498: vgPlain_scheduler (scheduler.c:721) > ==18707== by 0xB003BB99: thread_wrapper (syswrap-linux.c:86) > ==18707== by 0xB003BC5D: run_a_thread_NORETURN (syswrap-linux.c:119) > > so I guess there's definitely some work left to do on valgrind... yes :-/ actually, I haven't updated the wiki page lately - the good news: most of the points related to false positives is either in latest Wine and will be present in yet to come 3.1.1 (RC1 is for Friday this week) - the bad news: the SEH support is still deficient, and we still have stack issues (what you get). I updated the VG patch on the Wiki that fixes (for me) some errors that look very close to what you describe (the stack ones). As of today, the VG folks are rather sluggish to look at those issues and to integrate some of the patches. So, they won't be present for 3.1.1, perhaps for 3.2 (somewhere in April). A+ -- Eric Pouech

March 7, 2006

Re: wine 0.9.9 vs. Ned For Speed V -- already better

by Stefan Dösinger

> Here goes the log for running NFS5: PU, in win 0.9.9, the first version > which manages to allow NFS to initialize the video mode, apparently. The demo installer stops with a message box that DirectX7.0a is required. How did you get that game installed? Can you send me a +ddraw,+tid trace? The trace suggests multi-threaded Direct3D to me, which doesn't work yet. I haven't tested it with my code yet, because the installer failed. Stefan

March 7, 2006

Re: valgrinding mozilla on wine

by Dan Kegel

On 3/7/06, Dan Kegel <dank(a)kegel.com> wrote: > I'm trying to track down a wine crash in firefox > (http://bugs.winehq.org/show_bug.cgi?id=4762) > and thought valgrind might be helpful. So, following > http://wiki.winehq.org/Wine_and_Valgrind When I posted the above, I hadn't yet applied the patch mentioned in the wiki page. When I did, valgrind itself crapped out: ==18736== Warning: client switching stacks? SP change: 0xBE857B4C --> 0x48DFFF0 ==18736== to suppress, use: --max-stackframe=1174963364 or greater --18707-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --18707-- si_code=1; Faulting address: 0x57E58959; sp: 0x62527DA4 valgrind: the 'impossible' happened: Killed by fatal signal ==18707== at 0xB001AB5C: vgPlain_get_StackTrace2 (m_stacktrace.c:147) ==18707== by 0xB001AC31: vgPlain_get_StackTrace (m_stacktrace.c:331) ==18707== by 0xB000DDCF: vgPlain_record_ExeContext (m_execontext.c:199) ==18707== by 0xB0001116: create_MAC_Chunk (mac_malloc_wrappers.c:139) ==18707== by 0xB0001B17: vgMAC_malloc (mac_malloc_wrappers.c:203) ==18707== by 0xB002D9C3: do_client_request (scheduler.c:987) ==18707== by 0xB002D498: vgPlain_scheduler (scheduler.c:721) ==18707== by 0xB003BB99: thread_wrapper (syswrap-linux.c:86) ==18707== by 0xB003BC5D: run_a_thread_NORETURN (syswrap-linux.c:119) so I guess there's definitely some work left to do on valgrind... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Wine and OS X

by Obchod id

Hi, There could be at least mention in FAQ about possible OS x version or whether there is no plan. Best wishes Frantisek -- !!! Nová prodejna v Plzni. Od 9.11. otevíráme druhou prodejnu na Náměstí Republiky 21, v 1. patře přímo nad kanceláří Annonce, na zastávce tramvaje směr Slovany. Tel: 377 331 256!!! >>>Stesticko.cz - pro radostny a naplneny zivot. http://www.stesticko.cz > Knihkupectvi, internetovy a zásilkovy obchod http://shop.stesticko.cz >> Pecujeme o vase telo i dusi Knihy pro osobni rust, duchovno, esoteriku, hudba, tarot. karty, feng-shui Americka 20, Plzen, Po-Pa 9-18, So 10-12 h,tel: 377 91 91 73, 777 263 352 Namesti Republiky 21, Plzen, Po-Pa 10-18 h tel: 377 331 256, 608 702 719 > Alternativni knihovna a antikvariat http://www.stesticko.cz/knihovna/ >>> http://sweb.cz/wingmakers - Tvurci kridel - WingMakers.com <<<

March 7, 2006

Problem while compiling wine-0.9.9 source on solaris

by Vikas Gera

I tried to build Wine Library on Solaris 10 platform today. It gave error while compiling dll/dxerr8 module. The error message says "Don't know how to make target: install-lib" I compared the Makefiles and added the target "install-lib" for dxerr8 module, like below: Makefile: install install-lib:: install_lib $(WIN16_INSTALL) install_lib: $(MODULE) $(MKINSTALLDIRS) $(DESTDIR)$(dlldir) $(INSTALL_PROGRAM) $(MODULE) $(DESTDIR)$(dlldir)/$(MODULE) It was able to build the dxerr8 module. But similar error message is getting repeated for other modules as well. I would like to fix it in one shot, probably a fix in the configure script is needed. Has anybody faced this problem and fixed it? Please suggest. regards, Vikas Gera

March 7, 2006

valgrinding mozilla on wine

by Dan Kegel

I'm trying to track down a wine crash in firefox (http://bugs.winehq.org/show_bug.cgi?id=4762) and thought valgrind might be helpful. So, following http://wiki.winehq.org/Wine_and_Valgrind I installed valgrind-3.1.0 and ran valgrind --trace-children=yes /home/dank/wine/wine /home/dank/.wine/drive_c/Program\ Files/Mozilla\ Firefox/firefox.exe This got as far as putting up a window (but not filling it in) before croaking, so I guess valgrind still has some ways to go. Before it bailed, it printed out a few interesting warnings: ... ==16329== Warning: noted but unhandled ioctl 0x30B with no size/direction hints ==16329== This could cause spurious value errors to appear. ==16329== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==16329== ==16329== Syscall param writev(vector[...]) points to uninitialised byte(s) ==16329== at 0x20000772: (within /lib/ld-2.3.5.so) ==16329== by 0x202D2BD8: wine_server_call (in /home/dank/wine/dlls/ntdll/ntdll.dll.so) ==16329== by 0x202C85D3: NtSetValueKey (reg.c:755) ==16329== by 0x205BFFF8: create_scsi_entry (oldconfig.c:170) ==16329== by 0x205C07BD: convert_old_config (oldconfig.c:400) ==16329== by 0x205C482E: __wine_kernel_init (process.c:751) ==16329== by 0x202C0BB2: __wine_process_init (loader.c:2276) ==16329== by 0x2002448E: wine_init (loader.c:600) ==16329== by 0x7BF01001: main (main.c:58) ==16329== Address 0xBEBF0874 is on thread 1's stack ... err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 ==16329== ==16329== Invalid read of size 4 ==16329== at 0x600195C4: ??? ==16329== Address 0x208BE16C is not stack'd, malloc'd or (recently) free'd ==16329== ==16329== Conditional jump or move depends on uninitialised value(s) ==16329== at 0x463876: ??? ==16329== ==16329== Invalid read of size 4 ==16329== at 0x603514C4: ??? ==16329== Address 0x208BCC70 is not stack'd, malloc'd or (recently) free'd ... err:seh:segv_handler Got unexpected trap 0 err:seh:segv_handler Got unexpected trap 0 err:seh:segv_handler Got unexpected trap 0 ... -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

problem in configure/make wine 0.9.9

by Lalit Aggarwal

When I rum make command it shows the following error, can somebody please help me in to come out of this. Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o) ld: warning: Symbol referencing errors Tried editing /var/installs/wine-0.9.9/dlls/ddraw/Makefile at line number 367 and put the /var/installs/wine-0.9.9/dlls/kernel/environ.o after -o option, it build the shared object successfully. Can anybody suggest how to fix this in configure or config.status script so the environ.o file is automatically included in the Makefile. Thanks -Lalit

March 7, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 14:34 +0000, Huw D M Davies 쓰시길: > On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > Improved create_child_font_list(), get_nearest_charset(), more using > > font-linking mechanism. > > > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > > locale letter, (have to exist least one font corresponding current > > locale ). > > > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > > and If selected font is not support current ansi codepage, then it fixup > > > the problem in "create_child_font_list()" function. > > > > > > > I'm slightly confused about what you're trying to do here. Could you > try to explain it again please? > Sorry, my poor english... assume "Arial.ttf" is exist in the system. ------------------------------------------ string = "Hello. 안녕하세요. 安寕"; /* include non-western character */ logfont.lfCharSet = DEFAULT_CHARSET; logfont.lfFaceName = "Arial"; hfont = CreateFontIndirect(&logfont); SelectObject(hdc, hfont); TextOut(hdc, 10, 10, string, strlen(string)); -------------------------------------------- at this case, now Wine print out broken shape, because glyph missing on Arial.ttf. font-linking mechanism help this situation. but need to ------------------------------- [HKLM\\...\SystemLink] "Arial"="......" -------------------------------- New get_nearest_charset(), create_child_font_list() solve this situation without any additional config file change. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontex… ---------------------------------- Windows NT/2000/XP: DEFAULT_CHARSET is set to a value based on the current system locale. For example, when the system locale is English (United States), it is set as ANSI_CHARSET. ---------------------------------- Korean locale => HANGEUL_CHARSET, Japanese locale => SHIFTJIS_CHARSET. .... but, Arial.ttf is missing these charset, therefore incorrect operation in the get_nearest_charset(). Sorry again. Please see the code.... > Moving this TRACE is clearly not correct. Yes. I mistake...

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 03:01:34PM +0000, Huw D M Davies wrote: > The def* strings are supposed to be the default fallback names for the > various fonts. Here you just want to use the string "System", so > please leave it as it was. Actually, what you really want to use is SystemW[]. The def* strings should go at some point, but that's another story. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Repeatable crash in firefox

by Dan Kegel

This morning, using wine from cvs from a few days ago, I ran into a reproducible crash in firefox on wine. I have the Flash plugin installed; that might be involved, but the same recipe doesn't seem to crash Linux firefox. I filed http://bugs.winehq.org/show_bug.cgi?id=4762 for this; I'll try again with fresh cvs. -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 11:58:01PM +0900, Byeong-Sik Jeon wrote: > 2006-03-07 (화), 14:22 +0000, Huw D M Davies 쓰시길: > > > > Why don't you just use "tahoma.ttf" in the code where you call > > find_face_from_filename, there's no point in initializing a char > > string like this. > Yes. will be change to static const char Tahoma_ttf[] = "tahama.ttf"; Just remove the variable completely and call find_face_from_filenae("tahoma.ff") > > > - system_font_link->font_name = strdupW(System); > > > + system_font_link->font_name = strdupW(defSystem); > > > > Please don't use defSystem here. That's supposed to be a fallback for > > System. Please leave it as it was. > I can't understand. defSans, defFixed, defSerif is already using in the WineEngCreateFontInstance(). > this is different case? The def* strings are supposed to be the default fallback names for the various fonts. Here you just want to use the string "System", so please leave it as it was. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 14:22 +0000, Huw D M Davies 쓰시길: > On Tue, Mar 07, 2006 at 09:10:12PM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > init_system_links support .ttc file. > > add "Tahoma" registry value for CJK font link. > > find_face_from_filename support .ttc file > > > > I think you could spilt out the 'add Tahoma registry value' bit from > this patch to make it a little smaller. Yes. I understand. add_reg_value_system_font_link() will be removed. > > > --- 000/dlls/gdi/freetype.c 2006-03-07 19:09:53.000000000 +0900 > > +++ 001/dlls/gdi/freetype.c 2006-03-07 20:28:14.000000000 +0900 > > @@ -909,14 +935,16 @@ > > SYSTEM_LINKS *font_link, *system_font_link; > > CHILD_FONT *child_font; > > static const WCHAR Tahoma[] = {'T','a','h','o','m','a',0}; > > - static const WCHAR tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > > - static const WCHAR System[] = {'S','y','s','t','e','m',0}; > > + static const char Tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > > Why don't you just use "tahoma.ttf" in the code where you call > find_face_from_filename, there's no point in initializing a char > string like this. Yes. will be change to static const char Tahoma_ttf[] = "tahama.ttf"; > > > @@ -990,15 +1046,15 @@ > > that Tahoma has */ > > > > system_font_link = HeapAlloc(GetProcessHeap(), 0, sizeof(*system_font_link)); > > - system_font_link->font_name = strdupW(System); > > + system_font_link->font_name = strdupW(defSystem); > > Please don't use defSystem here. That's supposed to be a fallback for > System. Please leave it as it was. I can't understand. defSans, defFixed, defSerif is already using in the WineEngCreateFontInstance(). this is different case? Thanks.

March 7, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Improved create_child_font_list(), get_nearest_charset(), more using > font-linking mechanism. > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > locale letter, (have to exist least one font corresponding current > locale ). > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > and If selected font is not support current ansi codepage, then it fixup > > the problem in "create_child_font_list()" function. > > > I'm slightly confused about what you're trying to do here. Could you try to explain it again please? > --- 003/dlls/gdi/freetype.c 2006-03-07 20:29:58.000000000 +0900 > +++ 004/dlls/gdi/freetype.c 2006-03-07 20:30:31.000000000 +0900 > + if(!TranslateCharsetInfo((DWORD*)(INT)font->charset, &csi, TCI_SRCCHARSET)) > + return FALSE; > > + TRACE("found entry in system list\n"); > + > + fs.fsCsb[0] = fs.fsCsb[1] = 0; > LIST_FOR_EACH_ENTRY(font_link, &system_links, SYSTEM_LINKS, entry) > { > - if(!strcmpW(font_link->font_name, font->name)) > + if(!strcmpiW(font_link->font_name, font->name)) > { > - TRACE("found entry in system list\n"); Moving this TRACE is clearly not correct. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 09:10:12PM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > init_system_links support .ttc file. > add "Tahoma" registry value for CJK font link. > find_face_from_filename support .ttc file > I think you could spilt out the 'add Tahoma registry value' bit from this patch to make it a little smaller. > --- 000/dlls/gdi/freetype.c 2006-03-07 19:09:53.000000000 +0900 > +++ 001/dlls/gdi/freetype.c 2006-03-07 20:28:14.000000000 +0900 > @@ -909,14 +935,16 @@ > SYSTEM_LINKS *font_link, *system_font_link; > CHILD_FONT *child_font; > static const WCHAR Tahoma[] = {'T','a','h','o','m','a',0}; > - static const WCHAR tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > - static const WCHAR System[] = {'S','y','s','t','e','m',0}; > + static const char Tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; Why don't you just use "tahoma.ttf" in the code where you call find_face_from_filename, there's no point in initializing a char string like this. > @@ -990,15 +1046,15 @@ > that Tahoma has */ > > system_font_link = HeapAlloc(GetProcessHeap(), 0, sizeof(*system_font_link)); > - system_font_link->font_name = strdupW(System); > + system_font_link->font_name = strdupW(defSystem); Please don't use defSystem here. That's supposed to be a fallback for System. Please leave it as it was. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 10:45 +0000, Huw D M Davies 쓰시길: > As Mike has said the patch is too long to review properly, so please > break it down into much smaller pieces. > > On Tue, Mar 07, 2006 at 04:29:04PM +0900, Byeong-Sik Jeon wrote: > > and, I add some basic registry value. "Tahoma", "Gulim", "MS UI Gothic", > > "Simsun", "PMingLiU". > > One thing that caught my eye was that these strings are locale > dependent rather like the bitmap font strings (see update_font_info). Sorry, Huw. I understand. update_font_info() have to create the [HKLM\\Software\\Microsoft\ \Windows NT\\CurrentVersion\\FontLink\\SystemLink] and add Tahoma, etc value. it's more more better good approach. I'll remove add_reg_value_system_font_link().

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

I resended five splited patches. Thanks advice... 2006-03-07 (화), 16:58 +0900, Mike McCormack 쓰시길: > Byeong-Sik Jeon wrote: > > > ChangeLog: > > - add more font selecting & linking mechanism support. > > Nice work! > > Some comments: > > * Please split each fix into a separate patch. This makes patch reviews > and isolating regressions easier. A number of small patches will be > accepted into the Wine tree faster than one big patch. > > * There's also alot of unnecessary formatting changes in your patch, > which could be avoided. eg. > > > - LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) > > - { > > + LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) { > > * Please stick to coding style in the file you're change, so that we > don't end up with a mix of many different coding styles in the same > file. (and you don't add unnecessary changes like the above). > > thanks, > > Mike

March 7, 2006

Trying to fix bug 2400 - delete and comma

by agaro agaro

Hi all, I'm trying to fix bug 2400 - removes one char and puts comma simultaneously. My guess: this old bug is in dlls/x11drv/keyboard.c or dlls/user/message.c, something about dead keys implementation. Can somebody help me with a little explanation or documentation? I don't know what scancode, keycode and vkey mean. Thanks, agaro

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by H. Verbeet

On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > This doesn't really make sense to me - the point of unspecified behavior > if a parameter is NULL would be to speed up the function under contract > with the caller. If you're already doing the check, why not handle it in > some way other than crashing? Because we *want* to crash and get a nice backtrace. Since native d3d crashes when passed a NULL pointer, chances are that if we do get passed a NULL pParameters here, it is because we passed it to the application ourselves somewhere earlier. In the case of GetCreationParameters it's probably not very likely to get passed a NULL pointer anyway, but that's the general idea.

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 11:33 +0000, Huw D M Davies 쓰시길: > Right, but even Tahoma is locale dependent - the order of Gulim, MS UI > Gothic etc changes. Yes. but lucky thing... fsCsb[0] information of each font are: Gulim : ANSI, EASTEUROPE, RUSSIAN, GREEK, TURKISH, BALTIC, "HANGEUL" MS UI Gothic: ANSI, ASTEUROPE, RUSSIAN, GREEK, TURKISH, BALTIC, "SHIFTJIS" MingLiU : ANSI, "CHINESEBIG5" SimSun : ANSI, "GB2312" therefore, at japanese locale, if call "tahoma" then use "msgothic.ttc" (not "gulim.ttc"). But, I think that this is "FIXME" feature.

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Robert Reif

H. Verbeet wrote: >On 07/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > >>Native D3D crashes if it's called with a NULL pointer? Are you sure that you >>shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? >> >> >Yes. I verified that with DirectX 9.0c on win2k. > > > > > The Retail version of the dll might not check the parameters but the Debug version probably does.

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Ivan Gyurdiev

H. Verbeet wrote: > On 07/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > >> Native D3D crashes if it's called with a NULL pointer? Are you sure that you >> shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? >> > Yes. I verified that with DirectX 9.0c on win2k. > This doesn't really make sense to me - the point of unspecified behavior if a parameter is NULL would be to speed up the function under contract with the caller. If you're already doing the check, why not handle it in some way other than crashing? Anyway, I'm not familiar with wine development practices, so I wouldn't know whether this is the right thing to do - just wanted to point it out. I also see the same thing done in other wined3d patches.

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 08:22:36PM +0900, Byeong-Sik Jeon wrote: > 2006-03-07 (화), 10:45 +0000, Huw D M Davies 쓰시길: > > As Mike has said the patch is too long to review properly, so please > > break it down into much smaller pieces. > Yes. now working... Great. > > One thing that caught my eye was that these strings are locale > > dependent rather like the bitmap font strings (see update_font_info). > Yes. that is just thing like example, I will remove that. > > but, tahoma is important. "Tahoma" is linked at the "System" and, > many resource files use "MS Shell Dlg", and font substitutes "MS Shell > Dlg"="Tahoma". therefore, if font(gulim.ttc, msgothic.ttc, ...) is > exist, then we(CJK users) can see our latter at first start. > > just only "tahoma"... > HKLM: > [Software\\Microsoft\\Windows NT\\CurrentVersion\\FontLink\\SystemLink] > "Tahoma"=str(7):"Gulim.ttc,Gulim\0MsGothic.ttc,MS UI Gothic > \0SimSun.ttc,SimSun\0Mingliu.ttc,PMingLiU\0" Right, but even Tahoma is locale dependent - the order of Gulim, MS UI Gothic etc changes. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006