- Wine-Devel - list.winehq.org

winver
by puoti＠inwind.it Aug. 13, 2003

Aug. 13, 2003

I've noticed that wine doesn't yet seem to have a winver option for windows server 2003, I suppose it a trivial thing to implement, at least by seeing how quickly this was done for windows xp.

3 6

Re: Other winefile fixes
by Dimitrie O. Paun Aug. 13, 2003

Aug. 13, 2003

On August 13, 2003 09:25 am, Richard Cohen wrote: > Use __WINE instead of _WINE_, _WIN32 Why do we need to know that we're running under Wine in so many places? I think we have fewer tests for __WINE__ in a huge lib like wxWindows than we have in winefile! -- Dimi.

2 1

Re: wrong keyboard layout
by Dmitry Timoshkov Aug. 13, 2003

Aug. 13, 2003

"Phil Krylov" <phil(a)newstar.rinet.ru> wrote: > XFree86 -version reports: > > XFree86 Version 4.3.0 > Release Date: 27 February 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.4.22_pre2-gss i686 [ELF] > Build Date: 23 July 2003 > > The log you asked for is attached. It's rather big, so I truncated it > after ToUnicode entries. Here is your problem: trace:x11drv:x11drv_init_thread_data Using C locale of Input Method XFree86 uses C locale, not UTF-8 one. As I wrote previously, test with 'xev' first. As soon as it starts to work, Wine should work as well. -- Dmitry.

2 2

Re: Other winefile fixes
by Dimitrie O. Paun Aug. 13, 2003

Aug. 13, 2003

On August 13, 2003 09:25 am, Richard Cohen wrote: > Dimi, I have some patches for winegcc/winewrap. Are you working on it > at the moment, or should I just send them to wine-patches? Don't worry about me, send whatever you have to wine-patches. -- Dimi.

1 0

__stdcall__ pointer to member function
by Boaz Harrosh Aug. 13, 2003

Aug. 13, 2003

the GCC (3.2.2) compiler will not let me declare an __stdcall__ pointer to function member and code will than SEGFAULT on invocation of the member pointer. This is not the case for Regular pointers to functions. ( The compiler will also issue a warning on mismatch.) Listing of the Error: (BAD) class AFoo { public: __attribute__((__stdcall__)) void foo(int i ,int ii ,int iii) ; } ; __attribute__((__stdcall__)) void AFoo::foo(int i ,int ii ,int iii) { return ; } int main() { AFoo afoo ; void ( AFoo::*func)(int,int,int) ; func = &AFoo::foo ; for(int i=0 ; i < 0x8000000 ;i++) (afoo.*func)(1,2,3) ; // SEGFAULT or SEGIL when stack is Exhausted return 0 ; } any attempt to place the __atribute__((stdcall)) in the pointer declaration causes a compilation error. With out it the code will SEGFAULT. If declaring a regular pointer to function than no compilation error is issued and all is well. Listing of Regular function pointer: (GOOD) void __attribute__((stdcall)) foo(int i ,int ii ,int iii) { } int main() { void ( __attribute__((stdcall)) *func)(int,int,int) = &foo ; for(int i=0 ; i < 0x8000000 ;i++) (func)(1,2,3) ; return 0 ; } removing the __attribute__((stdcall)) from the *func declaration will rightfully issue a warning ( should be an error if you ask me, type mismatch). But Not so on our first example. !!!!!!!!!!!!!!!!!! Please if any body can help me? This totaly breaks COM. Is there a GCC switch to have all members (and pointers)__stdcall, to by pass this problem? Free Life Boaz

1 1

Re[2]: wrong keyboard layout
by Phil Krylov Aug. 13, 2003

Aug. 13, 2003

Hello Shachar, Tuesday, August 12, 2003, 12:15:51 AM, you wrote: SS> Dmitry Timoshkov wrote: >>BTW, what wrong happens if your keyboard was misdetected? In the current >>CVS all national characters should work fine regardless what keyboard >>layout was detected. Is that only a warning message which makes you worry? >> >> SS> Does this also apply to UTF-8? I, for one, still can't get any SS> characters recognized when the locale is UTF-8. With the current CVS, I can't get any Cyrillic input with any setting of LANG: ru_RU.KOI8-R, ru_RU.UTF-8, ru_RU.CP1251, and en_US.UTF-8. Only ? characters are input. -- Best regards, Phil mailto:phil(a)newstar.rinet.ru

2 7

Better GNOME integration
by Christian Neumair Aug. 13, 2003

Aug. 13, 2003

When trying to use the latest Debian package I noted that there are no MIME bindings available for GNOME and that applications installed with wine are not visible in the application menu. In my opinion the first issue is really easily solvable, just three more files need to be included in the package and copied into /usr/share/mime-info and /usr/share/application-registry - is the official source the right place or should package maintainers include this? The second is a bit more tricky. I propose that as a 1.0 target wine should implement the freedesktop.org menu spec [1], which is definitly the future. We should contact the freedesktop guys and tell them that we want a registered category "WINE" :). regs, Chris [1] http://www.freedesktop.org/standards/menu-spec/0.5-onehtml/

1 0

WCSToMBEx and MBToWCSEx
by Jonathan Wilson Aug. 13, 2003

Aug. 13, 2003

I have come up with some info on these 2 (previously undocumented) calls: DWORD STDCALL WCSToMBEx(WORD CodePage,LPWSTR UnicodeString,DWORD UnicodeSize,LPSTR *MBString,DWORD MBSize,BOOL Allocate); DWORD STDCALL MBToWCSEx(WORD CodePage,LPSTR MBString,DWORD MBSize,LPWSTR *UnicodeString,DWORD MBSize,BOOL Allocate); Return value for both is the count of characters copies (or mabie count of bytes, not sure) for WCSToMBEx, the parameters are: CodePage: specifies which code page to use (its the same code page as passed to WideCharToMultiByte) UnicodeString: the input unicode string UnicodeSize: the size of the unicode string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. MBString: the output ascii string MBSize: the size of the ascii string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. Allocate: Set to true to ask the function to allocate the destination memory. Set to false and it assumes that the memory is preallocated by the caller. For MBToWCSEx, the parameters are: CodePage: specifies which code page to use (its the same code page as passed to MultiByteToWideChar) MBString: the input ascii string MBSize: the size of the ascii string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. MBString: the output unicode string MBSize: the size of the unicode string (not sure if its bytes or characters). Pass -1 to ask the function to calculate it for you. Allocate: Set to true to ask the function to allocate the destination memory. Set to false and it assumes that the memory is preallocated by the caller. I am going to implement these functions and contribute the code to ReactOS & WINE but I want someone else to play whith them and confirm all my findings as to what these functions do and how they work first.

3 2

Question about dlls/dinput/mouse/main.c
by Michael Schlüter Aug. 12, 2003

Aug. 12, 2003

Hi, I've a small problem with the game "Star Trek Elite Force II Single Player Demo". The mouse button event seems not to be send back to the game. After changing the return value of dinput_mouse_hook in dlls/dinput/mouse/main.c to return always "CallNextHookEx( This->hook, code, wparam, lparam );" it works. Does anybody has a solution for that issue? Bye, Michael

1 0

Re: Implement a typelib loader cache
by Alexandre Julliard Aug. 12, 2003

Aug. 12, 2003

Mike Hearn <mike(a)theoretic.com> writes: > ChangeLog: > Implement a typelib loader cache You'll need to protect the list with a critical section. Also it's probably better to store the list directly in the typelib structure instead of allocating a separate object. -- Alexandre Julliard julliard(a)winehq.com

1 0