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

Re: event.c freezes on XFilterEvent

by Vik

Hi, Happy New Year! > If I were you I would contect Mike McCormack & Jon Griffiths...... Thanks for the lead, I believe most of the current XIM patch code we use came from Mike's patch in 2002, and a mix of many other people's patches. I'll see if I can get in touch with him... > I'm sure -debug info would be apprishiated.. I'm sure it is... although, I'm not too sure on how to go about doing this. I'm thinking the wine --debugmsg output is not going to help much, so when debugging something like this, would I have to go into gdb or something of that sorts? (sorry I'm still rather new to all this :) ) I suppose since the whole CJK support issue is on the TODO, it has to be dealt with some how sooner or later. I'm more than willing to invest some time on this, although I'm not sure how much I can do. I'll see if I can "fix" it first and submit a patch here for review... :) XIM and all can come later... It's more of an annoyance issue right now anyway, as I often hit shift+space by accident (while typing in English) and brings the application to a halt. One thing I can think of right now is to get rid of the XIM related calls and think about implementing it better. Although that might not be a good way to go about it... > only the russians and french can spell correct in english :-) (we speak > it, they fix spelling mistakes = 50/50) Hehe. The important thing I guess is to get the point across :-) Cheers Vik -- ------------ Vikram Kumar vik(a)zone81.com

Jan. 1, 2004

Re: Congradulations - windef.h

by Boaz Harrosh

Mike Hearn wrote: >On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote: > > >>Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy >>myself, and I've never used KDevelop, but I could maybe use some >>autocompletion :) >> >> > >If vim has something like emacs tag completion then you could use that - >I know etags works pretty well for me. I'm not saying you should use >emacs obviously, but I expect there is an equivalent or vimscript you >can use. > >Briefly, you can do "make etags" in the wine source root, wait a bit, >then two very useful features are available: > >M-. (find-tag) lets you locate any definition in the wine source tree >complete-tag lets you perform completion based upon those same tags. > >I typically just use dabbrev-expand though which searches files you have >open in the background for expansions. > > > Personally I use KDevelop for the debugger. Nothing like it save across the border at windows MSVC++. Well I guess I like the other stuff too. I'm originally a Macintosh person so anything GUI for me. KDevelop will let you feel more at home if you come from windows. You cannot use KDevelop 2.1 release with wine. Too many files to deep. It will crash trying to import that project. (After 10 minuets of a progress bar) here you have been warned. KDevelop 3 beta does not do any of that. It Just runs the makefile no Q asked. 3 seconds done. But be careful do not use the official beta release (or RPMs or DEBs) use only the latest snapshot. You'll have to compile it from source. and thanks for the "make etags" KDevelop likes that too ...

Jan. 1, 2004

Re: Congradulations - windef.h

by Mike Hearn

On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote: > Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy > myself, and I've never used KDevelop, but I could maybe use some > autocompletion :) If vim has something like emacs tag completion then you could use that - I know etags works pretty well for me. I'm not saying you should use emacs obviously, but I expect there is an equivalent or vimscript you can use. Briefly, you can do "make etags" in the wine source root, wait a bit, then two very useful features are available: M-. (find-tag) lets you locate any definition in the wine source tree complete-tag lets you perform completion based upon those same tags. I typically just use dabbrev-expand though which searches files you have open in the background for expansions.

Jan. 1, 2004

Re: Missing exports?

by Mike Hearn

On Thu, 2004-01-01 at 00:21, Alexandre Julliard wrote: > Same thing with dlls, unless there is a reason to > have a stub dll it's much better to not have one at all so that the > native one gets used. I guess it's a matter of long term vs short term thinking, but in that case why do we build MSHTML when we have no implementation for it, and probably won't for some time? Obviously we have to start somewhere, but I remember when MSHTML was first introduced some apps stopped working because we favour builtin DLLs over native ones, so everybody had to debug the problem (easy for people who can interpret stub FIXMEs and know what they mean) and then alter their config file to force mshtml to native. thanks -mike

Jan. 1, 2004

Re: unknwn.h: unknwn.idl

by Boaz Harrosh

Robert Shearman wrote: >>-----Original Message----- >>From: Ove Kaaven [mailto:ovek(a)arcticnet.no] >>Sent: 01 January 2004 01:34 >>To: Robert Shearman >>Cc: Boaz Harrosh; wine-devel(a)winehq.org >>Subject: RE: unknwn.h: unknwn.idl >> >>You can't use cpp_quote inside an interface definition. >> >> > >True, but you can use cpp_quote to disable interface generation using >cpp_quote("#if 0") ... cpp_quote("#endif"). This is how Microsoft do it with >their unknwn.idl. > > > point taken I'll have a look. But that means two things: 1) At .h file we have Dead C++ code with no use, then another c++ code duplicating most of the other code. 2) The code is duplicated any way. What is the difference if it is duplicated in two different files (.h & .idl) or if it is duplicated inside the same file? In any way it will have to be maintained by hand. One in MIDL syntax and one in C++ syntax. ( with cpp_quote( .. ) around it ). And all that for something that will never change ( :) ) I go for change the makefile. By the way. some thing funny. In MS headers from VC6 they do not have that thing in the .idl file at all. And the .h file is hand crafted. In one of the SDKs (the one I have) they have above solution but the supplied Header is not the result of that idl file. It looks like: Here is the header but if you accidentally compile the idl it will give you some ugly brother that works too. >>Apparently, MS didn't solve that problem, so widl hasn't either. >> >> > >Microsoft caused the problem. What is the point of creating this automatic >QueryInterface function? Is it that hard to pass in a matching IID with your >interface pointer? > > Well, Personally I like it. One less thing That I can screw up. Either it matches or it does not compile. I let the compiler do my job any day. Any way ATL will not compile with out it. And it cannot be fixed either. because a long chain of definitions relay at that chip of information been carried by the compiler down 5 layers of code. Look at it this way. One MS programmer hard codes COM in C the other one in ATL. Which one will finish first? Well the second one wrote IE. (I know bad example on purpose :) )

Jan. 1, 2004

Re: Renaming registry keys...

by Robert van Herk

Dimitrie O. Paun wrote: >On December 31, 2003 08:00 am, Robert van Herk wrote: > > >>I need such a thing for winecfg, but Win32 doesn't seem to have a >>RegKeyRename api-call... >> >> > >Why do you need the rename a key in winecfg? > > When someone configures app1.exe, and later on decides that he actually meant app2.exe, he might want to rename app1.exe to app2.exe, and so migrate all the settings.

Jan. 1, 2004

Re: New registry key adding patch

by Zimler Attila

Hi, I give it a third try :) Dimitrie O. Paun wrote: >On January 1, 2004 06:41 am, Zimler Attila wrote: > > >>This is working while "key name" string is not localized. >>After that this could introduce security bugs. >>Will it be localized? How to deal with situations like this? >> >> > >Well, we would need to allocate the buffer dynamically anyway. > > I don't understand this. Probably because I don't understand how we translate the "key name" string, to the localized version, and because this I have no idea how big memory should we allocate. >Please use uniffied diffs (diff -u) when submitting patches. > > > cvs diff -u is ok? (This is how I did it at this time) Hope everything is ok (except localization) at this time. Attila Index: programs/regedit/edit.c =================================================================== RCS file: /home/wine/wine/programs/regedit/edit.c,v retrieving revision 1.3 diff -u -u -r1.3 edit.c --- programs/regedit/edit.c 12 Dec 2003 04:08:59 -0000 1.3 +++ programs/regedit/edit.c 1 Jan 2004 12:06:32 -0000 @@ -91,6 +91,29 @@ return FALSE; } +BOOL CreateKey(HKEY hKey) +{ + LONG lRet; + HKEY retKey; + TCHAR keyName[32] = "new key"; + unsigned int keyNum = 1; + + /* If we have illegal parameter return with operation failure */ + if (!hKey) return FALSE; + + /* try to find out a name for the newly create key. + We try it max 100 times. */ + lRet = RegOpenKey(hKey, keyName, &retKey); + while (lRet == ERROR_SUCCESS && keyNum < 100) { + sprintf(keyName, "new key %u", ++keyNum); + lRet = RegOpenKey(hKey, keyName, &retKey); + } + if (lRet == ERROR_SUCCESS) return FALSE; + + lRet = RegCreateKey(hKey, keyName, &retKey); + return lRet == ERROR_SUCCESS; +} + BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName) { DWORD valueDataLen; Index: programs/regedit/framewnd.c =================================================================== RCS file: /home/wine/wine/programs/regedit/framewnd.c,v retrieving revision 1.5 diff -u -u -r1.5 framewnd.c --- programs/regedit/framewnd.c 12 Dec 2003 04:08:59 -0000 1.5 +++ programs/regedit/framewnd.c 1 Jan 2004 12:06:32 -0000 @@ -469,6 +469,9 @@ case ID_EDIT_COPYKEYNAME: CopyKeyName(hWnd, _T("")); break; + case ID_EDIT_NEW_KEY: + CreateKey(hKey); + break; case ID_REGISTRY_PRINTERSETUP: /*PRINTDLG pd;*/ /*PrintDlg(&pd);*/ Index: programs/regedit/main.h =================================================================== RCS file: /home/wine/wine/programs/regedit/main.h,v retrieving revision 1.8 diff -u -u -r1.8 main.h --- programs/regedit/main.h 12 Dec 2003 04:08:59 -0000 1.8 +++ programs/regedit/main.h 1 Jan 2004 12:06:32 -0000 @@ -93,6 +93,7 @@ extern LPCTSTR GetItemPath(HWND hwndTV, HTREEITEM hItem, HKEY* phRootKey); /* edit.c */ +BOOL CreateKey(HKEY hKey); BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName); #endif /* __MAIN_H__ */

Jan. 1, 2004

RE: unknwn.h: unknwn.idl

by Robert Shearman

> -----Original Message----- > From: Ove Kaaven [mailto:ovek(a)arcticnet.no] > Sent: 01 January 2004 01:34 > To: Robert Shearman > Cc: Boaz Harrosh; wine-devel(a)winehq.org > Subject: RE: unknwn.h: unknwn.idl > > You can't use cpp_quote inside an interface definition. True, but you can use cpp_quote to disable interface generation using cpp_quote("#if 0") ... cpp_quote("#endif"). This is how Microsoft do it with their unknwn.idl. > Apparently, MS didn't solve that problem, so widl hasn't either. Microsoft caused the problem. What is the point of creating this automatic QueryInterface function? Is it that hard to pass in a matching IID with your interface pointer?

Jan. 1, 2004

Re: Congradulations - windef.h

by Boaz Harrosh

Alexandre Julliard wrote: >"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > >>On December 31, 2003 04:38 am, Boaz Harrosh wrote: >> >> >>>they were/are protected, but I think it should be removed from winegcc >>>because they don't do the Job. >>> >>> >>Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h >>idea. In general, he does not like non-standard headers... >> >> > >No, I don't. Boaz, could you please explain a bit more why the >definitions in winegcc don't work for you? > > > In short __declspec( selectany ) && __declspec( thread ) It has been discussed before. Lots of reasons - Why header ? why not command line? 1. It is best if defines are in a header file and not on an hard-coded command-line. One would like to have the freedom to override default defines. For example: a windows dll project will have ten tons of dllimport/dllexport directives. The GCC will warn about it (I have 3.3.1). If in a header, one can nullify this directive and have clean compilation instead of tunning off warnings and miss on Fatal warnings (there are some warning in GCC that should be errors and make your program fly :( ). 2. If you inspect my patch you see that it is not that small. putting it all on a command line is not practical. 3. In an header you can do things that a command line can't. For example current code will do an __ONLY_IN_WINELIB(). Now winegcc will override that. Which means winegcc can not be used for wine compilation. And that makes it harder for a, one day, have MinGW/Wine set of Makefiles. (See ReactOS) (If you think about it, many wine dll's could be compiled as PE with MinGW and make no difference) Conclusion: winegcc should stick to command-line switches and translations of options. like include directories, extra libs and so on. All code related and defines should go to an header file. If you don't like the ms-extensions.h name than it can be winegcc.h. - What's new in the patch? 1. The main 2 things that are currently missing for me are: a) selectany vs weak and b) __declspec( thread ) vs __thread. These completely break under current implementation. The only way to go is with Ove's solution of mapping all options to defines and than overriding as necessary. (hard to do on a command line) 2. Please have a quick look on my current patch. I have done quite a comprehensive mappings of all __declspec's to GCC options. it should not be missed by winegcc users. - Conclusion: I do not like current proposed solution (windef.diff). These things do not belong in windef.h - proof of that they are absent from M$ windef.h. They belong in a special header that mediates between different compilers. (like msvc vs gcc in our case). One could use ComuC++ or borlandC++ or even Intel, to compile wine and also to compile his WineLib application. These compilers have their own partial support for Microsoft extensions. And could actually make a WineLib user's life a bit easier because of other gcc peculiarities that forces them to change perfectly good code. What I propose is to go and collect all these msvc'ism into one header and clean that mess away from pure wine headers. I promise to not save any efforts in doing so. (One does at most what one can do :) ) And before we decide about all that, please accept my current patch it will not touch winegcc users only make them miss some of the fun. Free life Boaz

Jan. 1, 2004

Re: New registry key adding patch

by Zimler Attila

Hi, I tried to remove objectionable codes. Here is the patch again. I used sprintf, because snprintf gives me a warning, that it is explicitly declared (stdio.h is included). This is working while "key name" string is not localized. After that this could introduce security bugs. Will it be localized? How to deal with situations like this? Attila diff -c -d -r -N wine/programs/regedit/edit.c wine.new_regkey/programs/regedit/edit.c *** wine/programs/regedit/edit.c 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/edit.c 2004-01-01 11:30:33.000000000 +0000 *************** *** 91,96 **** --- 91,120 ---- return FALSE; } + BOOL CreateKey(HKEY hKey) + { + LONG lRet; + HKEY retKey; + TCHAR keyName[32]; + unsigned int keyNum = 1; + + /* If we have illegal parameter return with operation failure */ + if (!hKey) return FALSE; + + /* try to find out a name for the newly create key. + We try it max 100 times. */ + sprintf(keyName, "new key"); + lRet = RegOpenKey(hKey, keyName, &retKey); + while (lRet == ERROR_SUCCESS && keyNum < 100) { + sprintf(keyName, "new key %u", ++keyNum); + lRet = RegOpenKey(hKey, keyName, &retKey); + } + if (lRet != ERROR_SUCCESS) return FALSE; + + lRet = RegCreateKey(hKey, keyName, &retKey); + return lRet == ERROR_SUCCESS; + } + BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName) { DWORD valueDataLen; diff -c -d -r -N wine/programs/regedit/framewnd.c wine.new_regkey/programs/regedit/framewnd.c *** wine/programs/regedit/framewnd.c 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/framewnd.c 2004-01-01 11:13:17.000000000 +0000 *************** *** 469,474 **** --- 469,477 ---- case ID_EDIT_COPYKEYNAME: CopyKeyName(hWnd, _T("")); break; + case ID_EDIT_NEW_KEY: + CreateKey(hKey); + break; case ID_REGISTRY_PRINTERSETUP: /*PRINTDLG pd;*/ /*PrintDlg(&pd);*/ diff -c -d -r -N wine/programs/regedit/main.h wine.new_regkey/programs/regedit/main.h *** wine/programs/regedit/main.h 2003-12-12 04:08:59.000000000 +0000 --- wine.new_regkey/programs/regedit/main.h 2004-01-01 11:04:41.000000000 +0000 *************** *** 93,98 **** --- 93,99 ---- extern LPCTSTR GetItemPath(HWND hwndTV, HTREEITEM hItem, HKEY* phRootKey); /* edit.c */ + BOOL CreateKey(HKEY hKey); BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName); #endif /* __MAIN_H__ */

Jan. 1, 2004