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

Re: DPA_Create/Search may be missing

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > > Do they consider a "reverse engineering" running > > 'dumpbin /exports comctl32.dll' ? > > Here's the answer I got from Danny Smith back in October last year: > > > The only ways you can determine the ordinal alias in absence of > > documentation is by reverse engineering or by trial and error. How > > were these determined? > > > > By pushing the limits on "clean room" development of the w32api, we > > jeopardise not only the mingw project but also other projects - cygwin, > > Watcom - that seek to provide tools mainly for ordinary developers (who > > get no value from having DPA_Clone and friends exposed in the import > > lib). Thanks. That's just another proof for ReactOS guys to make use of Wine headers and libraries instead of ones provided by MinGW. -- Dmitry.

Jan. 20, 2004

Re: winapi_test chokes on TITLEBARINFO

by Hans Leidekker

On Tuesday 20 January 2004 14:09, Francois Gouget wrote: > 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. That code is mixing up the use of a variable holding a string and a variable holding a reference. Put otherwise it forget's to dereference a scalar ref (similar to a C pointer variable) before using it. Patch below fixes it. -Hans Changelog: Fix misuse of scalar reference variable.

Jan. 20, 2004

RFC on our new initiative

by Jeremy Newman

>From the desk of Jeremy White (who is at LinuxWorld ATM). Hey folks, We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center. You can check it out at http://www.codeweavers.com/site/compatibility/ but I think it's fair to describe it as the appdb on steroids. I wanted to announce it here to give folks a sense of what we're up to, and to apologize a bit in advance for stepping on the toes of folks that have been doing good work within the appdb. However, the #1 problem we have had over the past year or so is how to handle all the many, many requests we get for applications not on our 'supported' list. We've basically ended up sending people away, which has been pretty unsatisfying. Further, we haven't had any good way of determining what our priorities should be; we follow major paying clients, but beyond that, we mostly just follow our gut hunches in establishing priorities. We hope to end that; this new center lets our customers vote for apps, and lets non customers make pledges. We can hopefully follow those pledges to get apps running (and we'd probably be open to having wine hackers committing to support apps in exchange for a piece of the pledges, but we haven't gotten there yet). We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine. The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning. We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump. I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off. I also believe in the tooth fairy and Santa Claus, so make what you will of that <grin>. At any rate, this is a brand new initiative for us; call it an 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make. Cheers, Jeremy -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

Jan. 20, 2004

Re: Oleaut32 tests fail

by Jon Griffiths

Hi, > Im not sure if I understand you, > Im using the current CVS version of oleaut32. I think you'll find its the native dll thats failing. I'll be resyncing again today though, so I'll check nothings changed to break builtin. 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

Jan. 20, 2004

winapi_test chokes on TITLEBARINFO

by Francois Gouget

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.

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Hans Leidekker

On Tuesday 20 January 2004 10:19, Dmitry Timoshkov wrote: > Do they consider a "reverse engineering" running > 'dumpbin /exports comctl32.dll' ? Here's the answer I got from Danny Smith back in October last year: > The only ways you can determine the ordinal alias in absence of > documentation is by reverse engineering or by trial and error. How > were these determined? > > By pushing the limits on "clean room" development of the w32api, we > jeopardise not only the mingw project but also other projects - cygwin, > Watcom - that seek to provide tools mainly for ordinary developers (who > get no value from having DPA_Clone and friends exposed in the import > lib). -Hans

Jan. 20, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Fabian Cenedese

>That shouldn't happen. Keyboard detection code always does a full round >of comparisons with every keyboard table in x11drv. Ahmm... I don't have keyboard problems, just out of curiosity: Would it speed up wine starting if the keyboard was configured fixed and wine wouldn't have to test all possible layouts? bye Fabi

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > Yes, I know those are documented nowadays. MinGW has prototypes for > those functions, no problem with that. It's the bit of information > that says that DPA_Create (and previously the other functions) is > exported as ordinal 328, and exported ordinal only. That's not > documented on MSDN and, they say, can only have been obtained > through "reverse engineering". Do they consider a "reverse engineering" running 'dumpbin /exports comctl32.dll' ? -- Dmitry.

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Hans Leidekker

On Monday 19 January 2004 20:46, Martin Fuchs wrote: > You are searching for documentation of DPA_Create() and DPA_Search() ? > Herer it is: [MSDN links] Yes, I know those are documented nowadays. MinGW has prototypes for those functions, no problem with that. It's the bit of information that says that DPA_Create (and previously the other functions) is exported as ordinal 328, and exported ordinal only. That's not documented on MSDN and, they say, can only have been obtained through "reverse engineering". -Hans

Jan. 20, 2004

Re: Oleaut32 tests fail

by Sylvain Petreolle

--- Jon Griffiths <jon_p_griffiths(a)yahoo.com> a écrit : > >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. Im not sure if I understand you, Im using the current CVS version of oleaut32. ===== 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

Jan. 20, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Dmitry Timoshkov

"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.

Jan. 20, 2004

Re: Unicode and CP_SYMBOL question.

by Dmitry Timoshkov

"Rein Klazes" <rklazes(a)xs4all.nl> wrote: > I am planning to create a patch that fixes MultiByteToWideChar and > WideCharToMultiByte, as well as removing the symbol code page from the > code page table. Please don't forget to remove the special case for CP_SYMBOL in dlls/kernel/locale.c,IsValidCodePage() as well. -- Dmitry.

Jan. 20, 2004

Re: GetCommandLine issue with Dungeon Keeper

by Mike Hearn

On Mon, 19 Jan 2004 21:34:54 +0100, Andreas Rosenberg wrote: > Here is the output of IDA pro after detecting the compiler (Visual C familiy). > So it could detect the C lib functions. Now it is nearly obvious how the bug > happens: So why does GetCommandLineA not show up in relay or snoop traces? Is it statically linked or something?

Jan. 19, 2004

Re: Typo fix in type names

by Mike Hearn

On Mon, 19 Jan 2004 22:45:18 +0100, Francois Gouget wrote: > On Mon, 19 Jan 2004, Peter Hunnisett wrote: >> They are correct as is and yes MS makes spelling mistakes. > Darn. No worse than us though. GTK has contained some amusing ones - foo_struct->childs is one off the top of my head :)

Jan. 19, 2004

Re: Fix dplayx initialisation

by Alexandre Julliard

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

Jan. 19, 2004

Re: readme 2

by Alexandre Julliard

"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

Jan. 19, 2004

Re: Typo fix in type names

by Francois Gouget

On Mon, 19 Jan 2004, Peter Hunnisett wrote: > They are correct as is and yes MS makes spelling mistakes. Darn. [...] > >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. Which SDK is that? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Jan. 19, 2004

Re: Hi (virus alert)

by Rolf Kalbermatter

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

Jan. 19, 2004

Re: Typo fix in type names

by Peter Hunnisett

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

Jan. 19, 2004

GetCommandLine issue with Dungeon Keeper

by Andreas Rosenberg

> 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). Here is the output of IDA pro after detecting the compiler (Visual C familiy). So it could detect the C lib functions. Now it is nearly obvious how the bug happens: The result of GetCommandLine is being copied into a buffer. Then the command line is being broken down into an array of char pointers. This array is being passed to the subroutine below. There the first element is being "sprintf"ed into a buffer from the BSS segment. After that the strrchr searches for a '\'. No check is performed if a '\' is found. ---------------------------------------- I found an interesting note in the MS documentation regarding GetCommandLine: Note: The name of the executable in the command line that the operating system provides to a process is not necessarily identical to that in the command line that the calling process gives to the CreateProcess function. The operating system may prepend a fully qualified path to an executable name that is provided without a fully qualified path. ---------------------------------------- .text:004D25C0 ; __stdcall WinMain(x,x,x,x) .text:004D25C0 _WinMain(a)16 proc near ; CODE XREF: start+159p .text:004D25C0 .text:004D25C0 arg_0 = dword ptr 4 .text:004D25C0 .text:004D25C0 mov eax, [esp+arg_0] .text:004D25C4 push 103h ; size_t .text:004D25C9 mov hInstance, eax .text:004D25CE call ds:GetCommandLineA .text:004D25D4 push eax ; char * .text:004D25D5 push offset PtrCommandLine ; char * .text:004D25DA call _strncpy .text:004D25DF add esp, 0Ch .text:004D25E2 mov ecx, offset PtrCommandLine .text:004D25E7 mov CounterArgs, 0 .text:004D25F0 .text:004D25F0 loc_4D25F0: ; CODE XREF: WinMain(x,x,x,x)+4Aj .text:004D25F0 ; WinMain(x,x,x,x)+7Aj ... .text:004D25F0 cmp byte ptr [ecx], 0 .text:004D25F3 jz loc_4D267B .text:004D25F9 .text:004D25F9 loc_4D25F9: ; CODE XREF: WinMain(x,x,x,x)+44j .text:004D25F9 mov al, [ecx] .text:004D25FB cmp al, 9 .text:004D25FD jz short loc_4D2603 .text:004D25FF cmp al, ' ' .text:004D2601 jnz short loc_4D2606 .text:004D2603 .text:004D2603 loc_4D2603: ; CODE XREF: WinMain(x,x,x,x)+3Dj .text:004D2603 inc ecx .text:004D2604 jmp short loc_4D25F9 .text:004D2606 ; --------------------------------------------------------------------------- .text:004D2606 .text:004D2606 loc_4D2606: ; CODE XREF: WinMain(x,x,x,x)+41j .text:004D2606 mov al, [ecx] .text:004D2608 test al, al .text:004D260A jz short loc_4D25F0 .text:004D260C cmp al, '"' .text:004D260E jnz short loc_4D2642 .text:004D2610 inc ecx .text:004D2611 xor eax, eax .text:004D2613 mov ax, CounterArgs .text:004D2619 inc CounterArgs .text:004D2620 mov ArgsArray[eax*4], ecx .text:004D2627 cmp byte ptr [ecx], 0 .text:004D262A jz short loc_4D2637 .text:004D262C .text:004D262C loc_4D262C: ; CODE XREF: WinMain(x,x,x,x)+75j .text:004D262C cmp byte ptr [ecx], '"' .text:004D262F jz short loc_4D263C .text:004D2631 inc ecx .text:004D2632 cmp byte ptr [ecx], 0 .text:004D2635 jnz short loc_4D262C .text:004D2637 .text:004D2637 loc_4D2637: ; CODE XREF: WinMain(x,x,x,x)+6Aj .text:004D2637 cmp byte ptr [ecx], '"' .text:004D263A jnz short loc_4D25F0 .text:004D263C .text:004D263C loc_4D263C: ; CODE XREF: WinMain(x,x,x,x)+6Fj .text:004D263C mov byte ptr [ecx], 0 .text:004D263F inc ecx .text:004D2640 jmp short loc_4D25F0 .text:004D2642 ; --------------------------------------------------------------------------- .text:004D2642 .text:004D2642 loc_4D2642: ; CODE XREF: WinMain(x,x,x,x)+4Ej .text:004D2642 xor eax, eax .text:004D2644 mov ax, CounterArgs .text:004D264A inc CounterArgs .text:004D2651 mov ArgsArray[eax*4], ecx .text:004D2658 cmp byte ptr [ecx], 0 .text:004D265B jz short loc_4D25F0 .text:004D265D .text:004D265D loc_4D265D: ; CODE XREF: WinMain(x,x,x,x)+ABj .text:004D265D mov al, [ecx] .text:004D265F cmp al, 9 .text:004D2661 jz short loc_4D266D .text:004D2663 cmp al, ' ' .text:004D2665 jz short loc_4D266D .text:004D2667 inc ecx .text:004D2668 cmp byte ptr [ecx], 0 .text:004D266B jnz short loc_4D265D .text:004D266D .text:004D266D loc_4D266D: ; CODE XREF: WinMain(x,x,x,x)+A1j .text:004D266D ; WinMain(x,x,x,x)+A5j .text:004D266D cmp byte ptr [ecx], 0 .text:004D2670 jz short loc_4D267B .text:004D2672 mov byte ptr [ecx], 0 .text:004D2675 inc ecx .text:004D2676 jmp loc_4D25F0 .text:004D267B ; --------------------------------------------------------------------------- .text:004D267B .text:004D267B loc_4D267B: ; CODE XREF: WinMain(x,x,x,x)+33j .text:004D267B ; WinMain(x,x,x,x)+B0j .text:004D267B mov ax, CounterArgs .text:004D2681 push offset ArgsArray .text:004D2686 push eax .text:004D2687 call sub_43D440 .text:004D268C add esp, 8 ----------------------- .text:0043D440 sub_43D440 proc near ; CODE XREF: WinMain(x,x,x,x)+C7p .text:0043D440 .text:0043D440 var_165 = byte ptr -165h .text:0043D440 var_164 = byte ptr -164h .text:0043D440 var_144 = byte ptr -144h .text:0043D440 var_124 = dword ptr -124h .text:0043D440 var_104 = dword ptr -104h .text:0043D440 CounterArgs = dword ptr 4 .text:0043D440 ArgsArray = dword ptr 8 .text:0043D440 .text:0043D440 sub esp, 168h .text:0043D446 push ebx .text:0043D447 push esi .text:0043D448 push edi .text:0043D449 mov ebx, 0FFFFFFFFh .text:0043D44E push ebp .text:0043D44F mov edi, offset aDungeonKeeper ; "Dungeon Keeper" .text:0043D454 mov ecx, ebx .text:0043D456 sub eax, eax .text:0043D458 repne scasb .text:0043D45A not ecx .text:0043D45C sub edi, ecx .text:0043D45E mov eax, ecx .text:0043D460 shr ecx, 2 .text:0043D463 mov esi, edi .text:0043D465 mov edi, offset aBullfrogShell ; "Bullfrog Shell" .text:0043D46A rep movsd .text:0043D46C mov ecx, eax .text:0043D46E push 6Eh .text:0043D470 and ecx, 3 .text:0043D473 rep movsb .text:0043D475 call sub_4D2000 .text:0043D47A add esp, 4 .text:0043D47D call timeGetTime .text:0043D482 push eax ; unsigned int .text:0043D483 call _srand .text:0043D488 mov ecx, [esp+17Ch+ArgsArray] .text:0043D48F add esp, 4 .text:0043D492 mov dword_509848, 0 .text:0043D49C mov edi, [ecx] .text:0043D49E sub eax, eax .text:0043D4A0 mov [esp+178h+var_165], 0 .text:0043D4A5 mov ecx, ebx .text:0043D4A7 repne scasb .text:0043D4A9 not ecx .text:0043D4AB sub edi, ecx .text:0043D4AD mov eax, ecx .text:0043D4AF shr ecx, 2 .text:0043D4B2 mov esi, edi .text:0043D4B4 lea edi, [esp+178h+var_104] .text:0043D4B8 rep movsd .text:0043D4BA mov ecx, eax .text:0043D4BC and ecx, 3 .text:0043D4BF rep movsb .text:0043D4C1 lea ecx, [esp+178h+var_104] .text:0043D4C5 push ecx .text:0043D4C6 push offset byte_552150 .text:0043D4CB call _sprintf .text:0043D4D0 add esp, 8 .text:0043D4D3 push '\' .text:0043D4D5 push offset byte_552150 ; char * .text:0043D4DA call _strrchr .text:0043D4DF add esp, 8 .text:0043D4E2 mov byte ptr [eax], 0 .text:0043D4E5 push 1 .text:0043D4E7 push 0 .text:0043D4E9 push 0 .text:0043D4EB call sub_4CDFB0

Jan. 19, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Shane Shields

On Sunday 18 January 2004 2:35 pm, Dmitry Timoshkov wrote: > The patch is wrong, since it cures just a symptom not the problem itself. That could be true as I havent looked too deeply into the code. It was just a quick look at that function only and wasnt followed completely through. (didnt want to step on toes). > 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. 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. 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)? > > 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. When I have some time (might be soon when this work is finished and I am out of a job) I will be looking into it. -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

Jan. 19, 2004

Re: DPA_Create/Search may be missing

by Martin Fuchs

On 19.01.2004 18:05:18 Hans Leidekker wrote: > On Sunday 18 January 2004 18:02, Francois Gouget wrote: > > > What about MinGW? It sounds like this test does not compile there > > either... > > Well, it compiles and links, but doesn't link at run-time > because MinGW's import lib exports these symbols by name, > not ordinal-only. > > I submitted a patch to correct this to MinGW but they > wouldn't accept it because of some documented-by-Microsoft-only > policy. You are searching for documentation of DPA_Create() and DPA_Search() ? Herer it is: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… As you may know, Microsoft lost its Anti-Trust process and had to make public some previous API - a lot of shell functions are a part of them. However they did "hide" them in a not very prominent place of MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… Regards, Martin

Jan. 19, 2004

Re: Unicode and CP_SYMBOL question. [?? Probable Spam]

by Rein Klazes

On Thu, 15 Jan 2004 19:24:25 +0800, you wrote: > > > > Apparently Windows uses something different. Probably we have to change > > > our internal map for Symbol encoding > > > > I will try a few other Windows versions first. It looks to me that > > Symbol encoding is not a real encoding at all apart from the 0xf000 > > offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably > > for that reason.. > > Sounds like a good idea. Please test and report here what you will find. It works as I described on everything from Win2K up to a recent Longhorn. On everything below that (NTx and win9x) the call fails. Further observations are that WideCharToMultiByte does the inverse (map 0-0x1f and 0xf020-0xf0ff, fail on everything else) and that EnumSystemCodePages() do not enum this code page (it does on wine). I am planning to create a patch that fixes MultiByteToWideChar and WideCharToMultiByte, as well as removing the symbol code page from the code page table. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 19, 2004

Re: DPA_Create/Search may be missing

by Jakob Eriksson

Hans Leidekker wrote: >On Sunday 18 January 2004 18:02, Francois Gouget wrote: > > > >>What about MinGW? It sounds like this test does not compile there >>either... >> >> > >Well, it compiles and links, but doesn't link at run-time >because MinGW's import lib exports these symbols by name, >not ordinal-only. > >I submitted a patch to correct this to MinGW but they >wouldn't accept it because of some documented-by-Microsoft-only >policy. > > Say again?! That's not very constructive. Microsoft documentation is not very good. Where can I start if I want to convert the Mingw minds? regards, Jakob

Jan. 19, 2004

Re: /dlls/gdi/freetype.c breakage

by Huw D M Davies

On Mon, Jan 19, 2004 at 11:08:09AM +0100, Gerald Pfeifer wrote: > 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. Looks like we're not finding freetype on your system for some reason. This should fix the compilation. -- Huw Davies huw(a)codeweavers.com Index: dlls/gdi/freetype.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/freetype.c,v retrieving revision 1.52 diff -u -r1.52 freetype.c --- dlls/gdi/freetype.c 18 Jan 2004 23:35:13 -0000 1.52 +++ dlls/gdi/freetype.c 19 Jan 2004 17:31:52 -0000 @@ -2518,7 +2518,7 @@ return FALSE; } -DWORD WineEngEnumFonts(LPLOGFONTW plf, DEVICEFONTENUMPROC proc, LPARAM lparam) +DWORD WineEngEnumFonts(LPLOGFONTW plf, FONTENUMPROCW proc, LPARAM lparam) { return 1; }

Jan. 19, 2004