December 2003 - Wine-Devel - list.winehq.org

Re: Congradulations - windef.h

by Boaz Harrosh

Thanks OK lets start with an oldy Just to see if I get the tools right: <patch> see attachment </patch> should I embed or attach? some explanations: The original Idea was proposed by Ove Kaaven (see __declspec(selectany) thread in wine-devel) The original Idea did not go so well because in lots of places these __declspecs would be again #defined by code and that #define 3-level indirection would confuse the compiler. Also this way one can see what is supported and what is not. I am afraid that I only checked that code compiles but did not write test cases where these constructs are usefully. (Also pretty_com.h & uuidof.h will come soon) IMPORTANT the above and other patches I will submit later are all, let's call them: Microsoft Extensions to the C/C++ compiler. they are currently scattered in a few headers here and also in msvcrt. (like wchar_t). I think WINE headers should, presuppose, and stay clean of "Microsoft Extensions" functionality and stay close to MS-headers as possible. All "Microsoft Extensions" should go into a special header and be included where needed like here. (windef.h) What do people think? should I go and collect all extensions to one header and remove them from where they currently are? This is also good for when one would need to compile with a compiler other than gcc. Dimitrie O. Paun wrote: >On December 29, 2003 01:36 am, Boaz Harrosh wrote: > > >> I have successfully Beta released a WinLib port of a, 1 million >>lines of code, windows program. QA will Install a first Linux Machine >>and will start to bang on it tomorrow. (Well more like an advanced Alfa >>I guess) >> >> > >Congratulations indeed! > > > >>Tomorrow I will start synchronization with wine current tree. Once I >>have it synced (2 days max). I will need someone to help me and guide me >>on how to send it all in. Dimi, will that be you? >> >> > >Sure, why not. The best way I think is to post them to wine-patches >(if you're fairly sure about the patches), and people will comment. >If you are unsure, post to wine-devel first, we'll refine the patches >there before they go to wine-patches. > > > ? windef.diff ? wine.kdevelop Index: include/windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.89 diff -u -r1.89 windef.h --- include/windef.h 24 Sep 2003 05:26:00 -0000 1.89 +++ include/windef.h 31 Dec 2003 08:04:32 -0000 @@ -113,14 +113,44 @@ #define FAR __ONLY_IN_WINELIB() #endif + #ifndef _MSC_VER + +// works well. Some times the exact placing veries with in the statment +#define __declspec_selectany __attribute__((weak)) +// ignored by GCC and is warned (supported by MinGW) +#define __declspec_dllexport __attribute__((dllexport)) +// ignored by GCC and is warned (supported by MinGW) +#define __declspec_dllimport __attribute__((dllimport)) +// works +#define __declspec_noreturn __attribute__ ((noreturn)) +// works +#define __declspec_nothrow __attribute__ ((nothrow)) +// works ?? +#define __declspec_naked __attribute__ ((naked)) + +// GCC is more restrictive about placing. look for TLS in gcc & msdn documentation +#define __declspec_thread __thread +// no paralle defined to nothing +#define __declspec_novtable +// Gcc only suports code ?? +#define __declspec_allocate(segname) __attribute__ (( section(segname) )) + +// property is supported thrugh the file pretty_com.h +// property( get=get_func_name|, put=put_func_name ) + +// _declspec( uuid() ) and __uuidof are supported with code changes +// see uuidof.h +#define __declspec_uuid(ComObjectGUID) error_SEE__uuidof_h__for_use_of_uuid + # ifndef _declspec -# define _declspec(x) __ONLY_IN_WINELIB() +# define _declspec(x) __declspec_##x # endif # ifndef __declspec -# define __declspec(x) __ONLY_IN_WINELIB() +# define __declspec(x) __declspec_##x # endif -#endif + +#endif //_MSC_VER #define CALLBACK __stdcall #define WINAPI __stdcall

Dec. 31, 2003

Re: MCI #4: Add support for many MCIWNDM_ messages and some MCI_ commands

by Tom

Dmitry Timoshkov wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > >>An explicit list of MCI_ commands/MCIWNDM_ messages/MCIWNDF_ flags >>would be much appreciated (if it's under 30ish items). This would >>give a much better indication of the amount of work left to do. > > > You are right, but it's too late today to put too much efforts on > it and I decided to at least send the completed work. Okay, its tommorow a list please........ Tom

Dec. 31, 2003

Re: GetModuleFileName mysteries

by Boaz Harrosh

Well there is now! Until recently 95% of the work was done on wine. WineLib was a side effect. Look what happens, if I have a "-wrap" application (C++) I need to place a link to it in WINEDLLPATH to even load. and also to all it's supporting DLLs (I know I have 36 of them). If any one is working on it, built in search should support both explicit Path loading, and executable directory. Same as native, Just that the PATH and system-folder changes to WINEDLLPATH. Once the built-in is found it's PATH should be recorded and later served on requests like GetModuleFileName and others. If no one else is doing it? It is the next thing on my list after all the current changes are submitted. And while we are at it. What is the wine policy about Built-in DLLs versions. I have encountered problems where setups where complaining about versions been "0.0.0.0" and also some other not high enough versions. Should we make a quick study about Windows versions and serve them as per WinVER reported? And Alexandre welcome back. I hope you had a good time and a well deserved rest. It was kind of gloomy around here with out you. Free Life Boaz Alexandre Julliard wrote: >"Ralf Juengling" <juenglin(a)cse.ogi.edu> writes: > > > >>But what is the reason for having GetModuleFileName return the system >>dir for "builtin DLLs"? >> >> > >Because we don't know the real path, and even if we did there is no >guarantee that it is accessible from a Windows drive. > > > >>Also, why does it behave differently for the two programs, as I reported >>in my initial posting; is one of the two cases exhibiting a bug? >> >> > >Because in one case you used a .exe.so and in the other a .dll.so, >they behave slightly differently. It's not really a bug, just a side >effect of the fact that you can load a .exe.so by specifying its path >explicitly, which you cannot do for builtin dlls. This could be >changed, but there hasn't been any real need for that yet. > > >

Dec. 31, 2003

event.c freezes on XFilterEvent

by Vik

Hi, I'm rather new to wine developement, and Xlib coding, and this is my first post to the list so bare with me please.... ;-) dlls/x11drv/event.c seems to freeze at XFilterEvent and brings the app to seizure ever since all the TSX functions have been gotten rid off... This is what happens: I run notepad, and start typing. Everything works fine until I hit shift+space which is the toggle for XIM (kinput in my case). Notepad freezes here. The trace on keyboard tells me that there is no character for the key combination and freezes right after; trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ffe1 >From my investigation, it seems that XFilterEvent (event.c, function process_events) <code> ignore = XFilterEvent( &event, None ); </code> is causing this. If I get rid of the whole check, and pass all the events to EVENT_ProcessEvent() , notepad would not freeze. XFilterEvent is supposed to return TRUE when the event is filtered by the XIM, but chances are that since the XIM functionalities are currently not really there, XFilterEvent cannot talk to the XIM context. As far as I remember when the TSX functions were there, the XIM window did pop up(despite XIM not working properly). I'm trying to trace the changes to see what might be causing this, but without much luck so far... I'm more than willing to try and fix this, as XIM support is critical for people from my part of the world (Japan, and most likely for Korea & China). We've been coming up with rather crude patches to have XIM work till now(upto 20031118), but can't get it to work because of this strange freezure we are experiencing.... Any pointers or thoughts will be greatly appreciated! Cheers Vik -- ------------ Vikram Kumar vik(a)zone81.com

Dec. 31, 2003

Re: event.c freezes on XFilterEvent

by Tom

Vik wrote: > Hi, > > I'm more than willing to try and fix this, as XIM support is critical for > people from my part of the world (Japan, and most likely for Korea & China). > We've been coming up with rather crude patches to have XIM work till now(upto > 20031118), but can't get it to work because of this strange freezure we are > experiencing.... > > Any pointers or thoughts will be greatly appreciated! If I were you I would contect Mike McCormack & Jon Griffiths...... I'm sure -debug info would be apprishiated.. (sorry for the spelling i'm of english decent) only the russians and french can spell correct in english :-) (we speak it, they fix spelling mistakes = 50/50) nasda, Tom > > Cheers > Vik >

Dec. 31, 2003

Re: Silly question, sloghtly off topic

by Boaz Harrosh

in WinNT (and decedents) security is implemented in kernel. So I would suspect that advapi32.dll is Just an interface to the kernel. I think allot of information about this thing and other you can find in http://sysinternals.com , Have a look. Joshua Walker wrote: >If you replace a win9x advapi32.dll with a winNT >advapi32.dll, do you gain the extra security features? >I'm guessing no... > >-Joshua > >

Dec. 31, 2003

Re: GetModuleFileName mysteries

by Tom

Boaz Harrosh wrote: > And while we are at it. What is the wine policy about Built-in DLLs > versions. I have encountered problems where setups where complaining > about versions been "0.0.0.0" and also some other not high enough > versions. Should we make a quick study about Windows versions and serve > them as per WinVER reported? I think we should add version info...? > > And Alexandre welcome back. I hope you had a good time and a well > deserved rest. It was kind of gloomy around here with out you. Yea....... Welcome back....... Tom, bows to your greatfull appearance.... should I say a buddhist chant now? (nom yo ho ring yo ho) or something to that effect. :) It's been a long time since buddhism........ Tom

Dec. 31, 2003

Re: Missing exports?

by Dan Kegel

Joshua Walker wrote: > So I'm still stumbling through advapi32 and there > seems to be some functions that were not exported. ANy > reason why? > > For example, AccessCheckByType was but > AccessCheckByTypeAndAuditAlarm, > AccessCheckByTypeResultList, > AccessCheckByTypeResultListAndAuditAlarm, > and AccessCheckByTypeResultListAndAuditAlarmByHandle > were not mentioned in the .spec file. Are these missed > exports? Do they need to be at least stubbed? If no app uses them, we probably shouldn't export them. Let cruft die. - Dan

Dec. 31, 2003

Re: Missing exports?

by Tom

Joshua Walker wrote: > > I know this all may seem bit anal, The more anal the merrier if you ask me....... what with about a > few thousand spec'ed APIs that need to be documented > and all. I think this is a grand idea! I would just like to fill in the blankes as > much as possable the first time through. I've already > had to backtrack three times to add intresting > comments I found important.(Function XYZ is only > avilible on WinNT 3.1 or higher) It would be nice to > at least have a fully spec'ed out DLL. Could you spec/stub out all the DX dlls? i'm verrrry aware that this could break some apps/games if a stub dlls is called. and in ceartin circumstances it may be best not to have a stub dll.... But there is a thing called .cvsignore and we coul'd just ignore the trouble makers untill there at a point of usability. And who knows I might jump in and try my hand at helping out. And i'm sure there are others out there who could chip in.. and if all goes well we could in the end have a nice DX implementation... So if your willing to spec/stub,,,, ill start with version resource's and go from there. Any other volunteers? Alexandre this is up to you I guess....... Can we ?? One way of looking at this is, we just want some space on http://cvs.winehq.org/ to work....collaborate..... And there are many examples of great things that happened from meager beginnings.. Tom > > -Joshua > >

Dec. 31, 2003

Missing exports?

by Joshua Walker

So I'm still stumbling through advapi32 and there seems to be some functions that were not exported. ANy reason why? For example, AccessCheckByType was but AccessCheckByTypeAndAuditAlarm, AccessCheckByTypeResultList, AccessCheckByTypeResultListAndAuditAlarm, and AccessCheckByTypeResultListAndAuditAlarmByHandle were not mentioned in the .spec file. Are these missed exports? Do they need to be at least stubbed? I know this all may seem bit anal, what with about a few thousand spec'ed APIs that need to be documented and all. I would just like to fill in the blankes as much as possable the first time through. I've already had to backtrack three times to add intresting comments I found important.(Function XYZ is only avilible on WinNT 3.1 or higher) It would be nice to at least have a fully spec'ed out DLL. -Joshua

Dec. 31, 2003