wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Still SSTab, OleAut32.dll
by Fabian Cenedese 22 Jan '04

22 Jan '04

Hi I'm still trying to get some VB programs to run on wine (actual cvs). But I always get the error that it can't load the SSTab control from TabCtl32.ocx as described here: http://www.winehq.org/hypermail/wine-devel/2003/12/0157.html I now tried setting some dlls to native and found that it works (well, further) if I set OleAut32.dll to native, the others are still builtin. What is missing? Has this to do with the typelib or anything else? Testcase is simple: Create a new VB(6)-Project and place the tab control (from TabCtl32.ocx which has to activated first) on the empty dialog. Run the exe on wine. Any pointers? Thanks bye Fabi

1 0

Re: WM_CTLCOLOR.. will be sent to parent window. [?? Probable Spam]
by Dmitry Timoshkov 22 Jan '04

22 Jan '04

<taro-x(a)justsystem.co.jp> wrote: > @@ -2665,12 +2665,27 @@ > static LRESULT > TREEVIEW_EraseBackground(TREEVIEW_INFO *infoPtr, HDC hDC) > { > - HBRUSH hBrush = CreateSolidBrush(infoPtr->clrBk); > - RECT rect; > + HBRUSH hBrushLocal = NULL; > + HWND hwnd = infoPtr->hwnd; > + HBRUSH hBrush = (HBRUSH)SendMessageW(GetParent(hwnd), > + IsWindowEnabled(hwnd) ? WM_CTLCOLOREDIT : WM_CTLCOLORSTATIC, > + (WPARAM)hDC, (LPARAM)hwnd); > + if (!hBrush) > + { > + hBrushLocal = CreateSolidBrush(GetBkColor(hDC)); > + hBrush = hBrushLocal; > + } 1. treeview has hwndNotify for sending notification messages, WM_CTLxxx messages can be sent to it as well. 2. In the case SendMessage(WM_CTLxxx) returns 0 (i.e. an app doesn't call DefWindowProc) you have to call DefWindowProc(WM_CTLxxx) yourself and not create an arbitrary brush. 3. Do not use C++ style comments. -- Dmitry.

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 22 Jan '04

22 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > "The patch is wrong, since it cures just a symptom not the problem itself. > There are two problems with current x11drv keyboard code: > 1. Very likely that Turkish keyboard layout there is incorrect. > 2. As stated before the keyboard code should be fixed to take into account > the real keyboard layout while building the keyc2vkey map, not the hardcoded > one." > > I have verified that (No. 1) the Turkish keyboard layout is correct so I am > now trying to work on No. 2. I'd expect that a correct keyboard layout should produce 0 (zero) number of mismatches... -- Dmitry.

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 21 Jan '04

21 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > X11 team tends to remove more than 2 characters per keysym. See > > /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more > > than 2 for some of them. Just do 'setxkbmap tr' and run Wine with > > +key,keyboard,+x11drv and look for mismatches. > > I have done that and piped the output to a logfile. Attached is an abbreviated > version with just the icelandic and turkish detection included. It seems to > be mismatching on detecting the third keysym where the key is defined > in /etc/X11/xkb/symbols/tr this could be a clue :) 15 mismatches per layout is too much. Isn't it? > TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d, > > in function X11DRV_KEYBOARD_DetectLayout where it should be > > TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d, 0x%04lX doesn't mean a truncation to 4 characters in format. > or my version of X11 is returning a larger value than it should. I suspect > this because of the large amount of calls to the function > KEYBOARD_MapDeadKeysym. Maybe the X11 guys have changed a short to a long > somewhere in my version of X11 (cvs 2003-11-24) or my gcc (3.2.2) has defined > them differently. If that is the case then the line > > ckey[i] = keysym & 0xFF; This piece of code gets executed only if XKB is disabled or couldn't translate keysym to a character. -- Dmitry.

2 1

Re: revised dsound mmap mapping patch
by Alexandre Julliard 21 Jan '04

21 Jan '04

Robert Reif <reif(a)earthlink.net> writes: > Moves dsound mmap mapping info into dsound objects. This is causing a test failure for me: dsound.c:340: Test failed: SetFormat failed: 0x8878000a -- Alexandre Julliard julliard(a)winehq.com

1 0

Stack limit error in newest release (not in olders)
by Anssi Hannula 21 Jan '04

21 Jan '04

When I run mircstats.exe, I get the following error: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. This didn't happen on older releases. What does this error message mean? The newest release also segfaulted, before I turned overcommit on. -- Anssi

1 0

control/numeric pad/alt keys
by Vik 21 Jan '04

21 Jan '04

Hi, Just noticed that control + whatever keycombination stopped working in head. Numeric Pad and Alt key combinations seems to be dead as well. Wondering if it's just me with my jp106 keyboard, or if anybody else has the same problem... Cheers Vik Here's the trace of --debugmsg +key notepad.exe when I pressed "ctrl + o". Instead of opening the file open dialog, it just outputs 'o' in the notepad window. trace:key:X11DRV_KeyEvent type 2, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=6F (o), # of chars=1 / 0x0f / '^O' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=00180001, InputKeyState=81 trace:key:TranslateMessage (WM_KEYDOWN, 004F, 00180001) trace:key:TranslateMessage Translating key VK_O (004f), scancode 18 trace:key:X11DRV_ToUnicodeEx (004F, 0018) : faked state = 0x0000 trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_ToUnicodeEx type 2, window 3400006, state 0x0000, keycode 0x0020 trace:key:X11DRV_ToUnicodeEx Translating char 0x6f to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 6f trace:key:TranslateMessage 1 -> PostMessageW(0x10022,WM_CHAR,006f,00180001) trace:key:TranslateMessage (WM_CHAR, 006F, 00180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0020 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 20 trace:key:X11DRV_KeyEvent keycode 0x20 converted to vkey 0x4f trace:key:X11DRV_KeyEvent bScan = 0x18. trace:key:queue_kbd_event wParam=004f, lParam=c0180001, InputKeyState=1 trace:key:TranslateMessage (WM_KEYUP, 004F, C0180001) trace:key:X11DRV_KeyEvent type 3, window 3400006, state 0x0004, keycode 0x0042 trace:key:X11DRV_KeyEvent state = 4 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 42 trace:key:X11DRV_KeyEvent keycode 0x42 converted to vkey 0x11 trace:key:X11DRV_KeyEvent bScan = 0x1d. trace:key:queue_kbd_event wParam=0011, lParam=c01d0001, InputKeyState=0 trace:key:TranslateMessage (WM_KEYUP, 0011, C01D0001) -- ------------ Vikram Kumar vik(a)zone81.com "Let the dogs bark, Sancho, it's a sign we're going in the right direction." -- Don Quixote

1 1

charset related compilation errors in authors.c
by Mike Hearn 21 Jan '04

21 Jan '04

Hi, I've carbon copied this to wine-devel. This looks like some charset/toolchain issue, but I'm not sure how to diagnose it. This is on Fedora Core 1 yes? What is the output of echo $LANG at the command prompt? Maybe one of our charset experts (hi dmitry! :) knows what's up. thanks -mike On Tue, 2004-01-20 at 20:17, jds wrote: > Hi Mike: > > Iam try the compile source the wine20031212, both have the problems in compiled. > > try with manual and ./tools/wineinstall, recive is the same errors: > > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/setupapi' > make[2]: Entering directory `/home/jds/wine-20031212/dlls/shell32' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_SHELL32_ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 > -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o authors.o authors.c > authors.c:19: error: stray '\366' in program > authors.c:20: error: `m' undeclared here (not in a function) > authors.c:20: error: initializer element is not constant > authors.c:20: error: (near initialization for `SHELL_Authors[18]') > authors.c:20: error: syntax error before string constant > authors.c:37: error: stray '\351' in program > authors.c:46: error: stray '\366' in program > authors.c:47: error: `rklund' undeclared here (not in a function) > authors.c:47: error: initializer element is not constant > authors.c:47: error: (near initialization for `SHELL_Authors[45]') > authors.c:47: error: syntax error before string constant > authors.c:53: error: stray '\370' in program > authors.c:71: error: stray '\351' in program > authors.c:72: error: `ron' undeclared here (not in a function) > authors.c:72: error: initializer element is not constant > authors.c:72: error: (near initialization for `SHELL_Authors[70]') > authors.c:72: error: syntax error before string constant > authors.c:73: error: stray '\363' in program > authors.c:73: error: `pez' undeclared here (not in a function) > authors.c:73: error: initializer element is not constant > authors.c:73: error: (near initialization for `SHELL_Authors[72]') > authors.c:73: error: syntax error before "Caravaca" > authors.c:172: error: stray '\347' in program > authors.c:172: error: `ois' undeclared here (not in a function) > authors.c:172: error: initializer element is not constant > authors.c:172: error: (near initialization for `SHELL_Authors[171]') > authors.c:172: error: syntax error before "Gouget" > authors.c:183: error: stray '\374' in program > authors.c:184: error: `nnewig' undeclared here (not in a function) > authors.c:184: error: initializer element is not constant > authors.c:184: error: (near initialization for `SHELL_Authors[182]') > authors.c:184: error: syntax error before string constant > authors.c:240: error: stray '\366' in program > authors.c:240:13: warning: multi-character character constant > authors.c:240: error: `rgy' undeclared here (not in a function) > authors.c:240: error: initializer element is not constant > authors.c:240: error: (near initialization for `SHELL_Authors[239]') > authors.c:240: error: syntax error before '\x4e6f67' > authors.c:245: error: stray '\351' in program > authors.c:246: error: `nez' undeclared here (not in a function) > authors.c:246: error: initializer element is not constant > authors.c:246: error: (near initialization for `SHELL_Authors[244]') > authors.c:246: error: syntax error before string constant > authors.c:248: error: stray '\351' in program > authors.c:249: error: `Johansen' undeclared here (not in a function) > authors.c:249: error: initializer element is not constant > authors.c:249: error: (near initialization for `SHELL_Authors[247]') > authors.c:249: error: syntax error before string constant > authors.c:288: error: stray '\345' in program > authors.c:289: error: `ven' undeclared here (not in a function) > authors.c:289: error: initializer element is not constant > authors.c:289: error: (near initialization for `SHELL_Authors[287]') > authors.c:289: error: syntax error before string constant > authors.c:315: error: stray '\366' in program > authors.c:316: error: `m' undeclared here (not in a function) > authors.c:316: error: initializer element is not constant > authors.c:316: error: (near initialization for `SHELL_Authors[314]') > authors.c:316: error: syntax error before string constant > authors.c:323: error: stray '\374' in program > authors.c:324: error: `hl' undeclared here (not in a function) > authors.c:324: error: initializer element is not constant > authors.c:324: error: (near initialization for `SHELL_Authors[322]') > authors.c:324: error: syntax error before string constant > authors.c:330: error: stray '\351' in program > authors.c:330: error: `Marcos' undeclared here (not in a function) > authors.c:330: error: initializer element is not constant > authors.c:330: error: (near initialization for `SHELL_Authors[329]') > authors.c:330: error: syntax error before "L" > authors.c:330: error: stray '\363' in program > authors.c:402: error: stray '\345' in program > authors.c:403: error: `rd' undeclared here (not in a function) > authors.c:403: error: initializer element is not constant > authors.c:403: error: (near initialization for `SHELL_Authors[401]') > authors.c:403: error: syntax error before string constant > authors.c:408: error: stray '\351' in program > authors.c:408: error: `Manuel' undeclared here (not in a function) > authors.c:408: error: initializer element is not constant > authors.c:408: error: (near initialization for `SHELL_Authors[407]') > authors.c:408: error: syntax error before "Ferrer" > authors.c:482: error: stray '\374' in program > authors.c:483: error: `ter' undeclared here (not in a function) > authors.c:483: error: initializer element is not constant > authors.c:483: error: (near initialization for `SHELL_Authors[481]') > authors.c:483: error: syntax error before string constant > authors.c:613: error: stray '\305' in program > authors.c:613: error: stray '\366' in program > authors.c:613: error: `ngstr' undeclared here (not in a function) > authors.c:613: error: initializer element is not constant > authors.c:613: error: (near initialization for `SHELL_Authors[612]') > authors.c:613: error: syntax error before "m" > make[2]: *** [authors.o] Error 1 > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/shell32' > make[1]: *** [shell32] Error 2 > make[1]: Leaving directory `/home/jds/wine-20031212/dlls' > make: *** [dlls] Error 2 > > Compilation failed, aborting install. > > Helpme please. > > Regards > > > > ---------- Original Message ----------- > From: Mike Hearn <mike(a)theoretic.com> > To: jds <jds(a)soltis.cc> > Sent: Mon, 19 Jan 2004 09:05:11 +0000 > Subject: Re: install problems IE with fresh winehq > wine-20031212-1fc1winehq.i686.rpm > > > On Sun, 2004-01-18 at 17:35, jds wrote: > > > Hi Mike: > > > I try the intall IE with you script install-ie6.sh in Fedora 1, fresh > intall > > > wine-20031212-1fc1winehq.i686, kernel 2.4.22-1.2149 > > > > > > The process no finish, pause in 72% in recive this errors: > > > > This is a known problem. For now please install Wine from WineHQ > > sources. I'm working on fixing this but the problem is a subtle one. > > > > thanks -mike > ------- End of Original Message ------- >

3 4

UXTHEME regression [was Re: install problems IE with fresh winehq wine-20031212-1fc1winehq.i686.rpm]
by Mike Hearn 21 Jan '04

21 Jan '04

On Wed, 2004-01-21 at 06:57, jds wrote: > 0x40fc2453 (UXTHEME.DLL.GetThemeSysString+0x4e3 in UXTHEME.DLL): incl 0x0(%esi) > Wine-dbg>quit A large UXTHEME update was committed in the last few days. It appears this causes the IE installer to crash. I'm currently bogged down with exams, it'll go on my list of regressions to track down and nail, but may take a few days or weeks, depending on how things go here. For now I'd suggest using 20031212, CVS is highly unstable and iesetup regresses all the time at the moment. I've copied this one to wine-devel as well so Kevin can see the crash. thanks -mike

1 0

Re: Variant tests
by Sylvain Petreolle 21 Jan '04

21 Jan '04

Jon, > Sylvain, can you apply the attached patch and send me the full output of > running the 2 tests? I can't duplicate the failures you are seeing with any > oleaut32 version here, but testing with a really really old version lead to > some changes that may help. These failures were given by the current oleaut32 CVS. (not by a real Windows box!) Now with this patch applied (updating CVS), I get : - no failure for vartest - 24 failures for vartype. (logs attached) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Variant tests
by Dmitry Timoshkov 21 Jan '04

21 Jan '04

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Dmitry, this should fix the test failing on your Win2K box also. If > it doesn't please let me know. A failure I reported is fixed now. Thanks! -- Dmitry.

1 0

winapi_test chokes on TITLEBARINFO
by Francois Gouget 21 Jan '04

21 Jan '04

When I run ./tools/winapi/winapi_test it chokes on the TITLEBARINFO declaration in winuser.h: typedef struct tagTITLEBARINFO { DWORD cbSize; RECT rcTitleBar; DWORD rgstate[CCHILDREN_TITLEBAR+1]; } TITLEBARINFO, *PTITLEBARINFO, *LPTITLEBARINFO; include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type ('DWORD') ('CCHILDREN_TITLEBAR+1') Can't use string ("4") as a SCALAR ref while "strict refs" in use at tools/winapi/c_type.pm line 283. I believe this is because it does not know how to compute the value of 'CCHILDREN_TITLEBAR+1'. Though I'm not sure the second error is really related to the first one. I had a look but I'm pretty lost in the winapi code. Does anyone know how to fix this problem? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 4

Re: Fix dashed/solid line in Postscript output
by Alexandre Julliard 21 Jan '04

21 Jan '04

Blake Leverett <bleverett(a)att.net> writes: > Index: dlls/wineps/ps.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/ps.c,v > retrieving revision 1.23 > diff -u -r1.23 ps.c > --- dlls/wineps/ps.c 8 Dec 2003 21:40:27 -0000 1.23 > +++ dlls/wineps/ps.c 16 Jan 2004 05:26:55 -0000 > @@ -508,6 +508,7 @@ > BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev) > { > char buf[256]; > + static char *last_dash = NULL; You can't use a static variable here, this would need to be stored in the device structure. But it's probably easier to always set the dash style unconditionally. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 20 Jan '04

20 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > There are two problems with current x11drv keyboard code: > > 1. Very likely that Turkish keyboard layout there is incorrect. > > AFAICT The Turkish keyboard layout is correct. X11 team tends to remove more than 2 characters per keysym. See /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more than 2 for some of them. Just do 'setxkbmap tr' and run Wine with +key,keyboard,+x11drv and look for mismatches. > The original code doesnt get as > far as looking at the turkish definition. From what I could determine it > stopped searching when it got a wrong keysymb and if that combination > satisfied the selection that keyboard was chosen. That shouldn't happen. Keyboard detection code always does a full round of comparisons with every keyboard table in x11drv. > It didnt matter if it was > the right keyboard or not. This was not completely verified through testing > as I only have one keyboard :) > > 2. As stated before the keyboard code should be fixed to take into account > > the real keyboard layout while building the keyc2vkey map, not the > > hardcoded one. > > That would be a more elegant and portable fix. How do the other programs do it > (read window managers)? Other programs have no constrains implied by implementing Win32 APIs on the top of X11. -- Dmitry.

3 3

shell32 patch 10
by Martin Fuchs 20 Jan '04

20 Jan '04

Changelog: - implemented SHGetRealIDL() Index: pidl.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/pidl.c,v retrieving revision 1.96 diff -u -p -d -r1.96 pidl.c --- pidl.c 18 Jan 2004 22:08:46 -0000 1.96 +++ pidl.c 20 Jan 2004 21:32:24 -0000 @@ -688,6 +688,7 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL /* TRACE(pidl,"--new pidl=%p\n",pidlNew);*/ return pidlNew; } + /************************************************************************* * SHGetRealIDL [SHELL32.98] * @@ -695,10 +696,37 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL */ HRESULT WINAPI SHGetRealIDL(LPSHELLFOLDER lpsf, LPCITEMIDLIST pidlSimple, LPITEMIDLIST *pidlReal) { - FIXME("sf=%p pidlSimple=%p pidlReal=%p\n", lpsf, pidlSimple, pidlReal); + UINT cfShellIDList = RegisterClipboardFormatA(CFSTR_SHELLIDLIST); - pdump (pidlSimple); - return 0; + STGMEDIUM medium = {0, {0}, 0}; + FORMATETC fmt = {cfShellIDList, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL}; + + IDataObject* pDataObj; + HRESULT hr = IShellFolder_GetUIObjectOf(lpsf, 0, 1, &pidlSimple, &IID_IDataObject, 0, (LPVOID*)&pDataObj); + + if (SUCCEEDED(hr)) { + hr = IDataObject_GetData(pDataObj, &fmt, &medium); + + IDataObject_Release(pDataObj); + + if (SUCCEEDED(hr)) { + /*assert(pida->cidl==1);*/ + LPIDA pida = (LPIDA)GlobalLock(medium.hGlobal); + + LPCITEMIDLIST pidl_folder = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[0]); + LPCITEMIDLIST pidl_child = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[1]); + + *pidlReal = ILCombine(pidl_folder, pidl_child); + + if (!*pidlReal) + hr = E_OUTOFMEMORY; + + GlobalUnlock(medium.hGlobal); + GlobalFree(medium.hGlobal); + } + } + + return hr; } /*************************************************************************

1 0

Re: DPA_Create/Search may be missing
by Alexandre Julliard 20 Jan '04

20 Jan '04

Francois Gouget <fgouget(a)free.fr> writes: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. What version of comctl32 is that? -- Alexandre Julliard julliard(a)winehq.com

7 18

Re: Oleaut32 tests fail
by Jon Griffiths 20 Jan '04

20 Jan '04

Hi, >Running the oleaut32 tests shows that vartype and vartest are >failing. >Has someone an idea about these ? Your (presumably early) version of oleaut32.dll doesn't support the VT_DECIMAL type. I'll update the tests shortly. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

Unicode and CP_SYMBOL question.
by Rein Klazes 20 Jan '04

20 Jan '04

Hi, Trying to fix a problem with Win2K's charmap.exe, I have a question for the unicode experts. If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K system, like in this snippet: char c;WCHAR w; for( c = 32; c; c++) MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1); I get that w == c + 0xf000 ( codes 0-31 are unchanged, any flag setting makes the function fail). Wine's implementation of MultiByteToWideChar() does something quite complicated based on standard unicode tables and returns Unicode characters in all kind of ranges. The loop above is basically what Win2K's charmap.exe does. Of course it does not properly display symbol fonts like "Symbol". Is there any reason why in this case MultiByteToWideChar should not do w = c + 0xf000 ? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 5

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 19 Jan '04

19 Jan '04

Andreas Rosenberg: >If somebody could provide me the problematic exe of DK and the address >where the crash occurs I will put it through IDA pro. This might help lifting the >mystery. If IDA pro detects which compiler suite has been used to link the EXE, >it should be "easy" to detect where the string came from http://ftp.sunet.se/pub/pc/games/pcgameworld/demos/dkdemo.zip Unzip it, run KDDATA -d, and keeper95 is the executable From my notes (I dont have Linux to hand just now): Trap occurs ar 0x43d4e2 At this point in time the path/exe is in 0x552150 On windows: This was copied from 0x12fe20 (Was already filled in at a breakpoint at 0x43d4ba) which in turn came from 0x141ee0 when the pgm is very first loaded (windbg or msdev prior to executing any code). Jason

3 2

Re: Typo fix in type names
by Peter Hunnisett 19 Jan '04

19 Jan '04

They are correct as is and yes MS makes spelling mistakes. Francois Gouget wrote: >In dlls/dplayx/lobbysp.h I found types and a field with a typo: > SPDATA_BUILDPARENTALHEIRARCHY > LPSPDATA_BUILDPARENTALHEIRARCHY > LPSP_BUILDPARENTALHEIRARCHY > BuildParentalHeirarchy > >I checked in the latest Microsoft SDK and in the DirectX 9.0a SDK and >couldn't find any type with a spelling of 'HEIRARCHY'. I also searched >on Google and could not find them here either. However I did not find >these types with the correct spelling either. > >That may be because these are internal types (they are defined in an >internal header after all), or because they are badly documented. > > This is the case. They're from a not really often distributed SDK. Ciao, Peter

3 2

Re: Fix dplayx initialisation
by Alexandre Julliard 19 Jan '04

19 Jan '04

Sylvain Petreolle <spetreolle(a)yahoo.fr> writes: > Trying to load dplayx returns error 487 (ERROR_INVALID_ADDRESS) for > now. > > The following change lets wine determine a memory space by itself. This won't work, the code needs the address to be the same in all processes. This has to be fixed first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: readme 2
by Alexandre Julliard 19 Jan '04

19 Jan '04

"Ivan Leo Murray-Smith" <puoti(a)inwind.it> writes: > OK, it uses winehq.org this time, and hopefully doesn't mess up the readme.fr There's no reason to change these URLs at all, the existing ones work just fine. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Hi (virus alert)
by Rolf Kalbermatter 19 Jan '04

19 Jan '04

Joshua Walker <halkun2002(a)yahoo.com> wrote: >3) If Microsoft just removed the ability to run >executables from Outlook, and made it so the user >would have to "activate" it via a executable >permission (Chmod 755 wsmktvxhew.exe) 99% of these >things won't even propgate. They actually did!! I seem not to be able to even extraxt an exe or other executable file attachment from any mail in Outlook 2000 at all. Even if I know for sure it is safe I can't get at it and had to ask the sender to resend it in ZIP format in the past. Didn't try to hard to find a config option 15 levels deep in some configuration settings though, but just decided they had overdone themselves ;-) Rolf Kalbermatter

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 19 Jan '04

19 Jan '04

"Sylvain Petreolle" <spetreolle(a)yahoo.fr> wrote: > Forwarded fom wine-users. > The keyboard detection when starting wine does not detect my turkish keyboard > and choses a scandinavion keyboard instead. I had a look at the keyboard.c > and there is a turkish keyboard defined. I found in the > X11DRV_KEYBOARD_DetectLayout function that the keysym detection loop exited > at the first wrong match which resulted in an incorrect match for the > keyboard. Attached is a patch that appears (for me) to solve this problem. > This problem has been evident since before cvs 2003-12-13. Wine still states > that it is unable to find the correct keyboard but it at least loads and uses > the correct definition although some keys don't work correctly. The patch is wrong, since it cures just a symptom not the problem itself. There are two problems with current x11drv keyboard code: 1. Very likely that Turkish keyboard layout there is incorrect. 2. As stated before the keyboard code should be fixed to take into account the real keyboard layout while building the keyc2vkey map, not the hardcoded one. Regarging Office 97 and Quicken problems: it's better to start with simple +relay trace and search for MessageBox and the first occurence of the wrongly formatted date respectively. Or just find a patch which caused a regression for Office97. -- Dmitry.

2 1

/dlls/gdi/freetype.c breakage
by Gerald Pfeifer 19 Jan '04

19 Jan '04

The following patch to dlls/gdi/freetype.c revision 1.52 date: 2004/01/18 23:35:13; author: julliard; state: Exp; lines: +3 -4 Use the exported FONTENUMPROCW as parameter in the EnumDeviceFonts driver function instead of defining a private function type. breaks compilation freetype.c:2521: error: syntax error before "DEVICEFONTENUMPROC" freetype.c: In function `WineEngEnumFonts': freetype.c:2522: error: number of arguments doesn't match prototype gdi_private.h:220: error: prototype declaration on a system with FreeType 2.1.4 and XFree86 4.3.0. The problem seems that DEVICEFONTENUMPROC is not defined, though on some of my other test boxes with slightly different versions of FreeType, I did not see this problem. http://www.rtp.freebsd.org/~gerald/config.h contains the config.h file from autoconf. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 1

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