wine-devel January 2004

129 participants
360 discussions

Re: REBAR: on a RB_SETBANDINFO message only redraw the rebar if something changed

by Dimitrie O. Paun

On January 2, 2004 10:50 am, Mike McCormack wrote: > This stops IE's toolbar from flickering when moving the mouse over links. Happy, happy, joy, joy... Thanks Mike!!! -- Dimi.

20 years, 4 months

Re: lParam of WM_CREATE for MDI children

by Steven Edwards

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > applications use something like the following code in order to pass > a custom parameter to a newly created MDI child: <snip> > Any ideas how to proceed without breaking too much assumptions in > the current code? You may want to take a look at the ReactOS implementation of MDI as we have done quite a bit of work on this and shell32 of late to get the ReactOS Explorer working. I dont know if Filip or Martin has already fixed the MDI bugs but if so we should have something to merge when Alexandre gets back. Thanks Steven __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

20 years, 4 months

unknwn.h: unknwn.idl

by Boaz Harrosh

2 Questions 1) if I do "make depend" than edit unknwn.idl (or any other idl) than do "make" should a new unknwn.h be compiled? Well it does not. If I "cd include" and "make" than nothing is done either. only if I do "make unknwn.h" it will compile. 2) In order for ATL to compile I need below code in my unknwn.h file. I could not fined a way to do it with WIDL. I have looked in Microsoft (vc6) header/idl and it looks they had the same problem. And below code was added by hand. Now if the answer to Q1 is "No not done automatically" than I guess I can submit a patch for unknwn.h only. could I also submit a patch to include/Makefile.in to remove unknwn.idl from the list of idl files so it will not accidentally over-write unknwn.h? <unknwn.h snippet> ... DEFINE_GUID(IID_IUnknown, 0x00000000, 0x0000, 0x0000, 0xc0,0x00, 0x00,0x00,0x00,0x00,0x00,0x46); #if defined(__cplusplus) && !defined(CINTERFACE) #if !defined(WINE_NO_UUIDOF) #include <wine/uuidof.h> extern "C++" { #endif #ifdef ICOM_USE_COM_INTERFACE_ATTRIBUTE struct __attribute__((com_interface)) IUnknown #else struct IUnknown #endif { virtual HRESULT STDMETHODCALLTYPE QueryInterface( REFIID riid, void** ppvObject) = 0; virtual ULONG STDMETHODCALLTYPE AddRef( ) = 0; virtual ULONG STDMETHODCALLTYPE Release( ) = 0; #if !defined(WINE_NO_UUIDOF) template <class Q> HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp) { return QueryInterface(__uuidof(Q), (void**)pp); } #endif }; #if !defined(WINE_NO_UUIDOF) } // extern "C++" #endif #else ... </unknwn.h snippet> I have tried below simple idl code but it will go to all the wrong places <bad unknwn.idl code> ... interface IUnknown { typedef [unique] IUnknown *LPUNKNOWN; HRESULT QueryInterface( [in] REFIID riid, [out, iid_is(riid)] void **ppvObject); ULONG AddRef(); ULONG Release(); cpp_quote("#if !defined(WINE_NO_UUIDOF)") cpp_quote("template <class Q>") cpp_quote("HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp)") cpp_quote("{") cpp_quote(" return QueryInterface(__uuidof(Q), (void**)pp);") cpp_quote("}") cpp_quote("#endif") } cpp_quote("#if !defined(WINE_NO_UUIDOF)") cpp_quote("} /*extern C++*/") cpp_quote("#endif") ... </bad unknwn.idl code>

20 years, 4 months

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

20 years, 4 months

Re: DMUSIC: my latest work

by Dimitrie O. Paun

On January 1, 2004 04:25 am, Rok Mandeljc wrote: > Hey everyone, > > I finally found some time to organise my dmusic work of last two months > in useful patch. Dmusic is now DX9 compatible, we have almost fully > implemented (but not working :( ) > IDirectMusicCollection/IDirectMusicInstrument, fully implemented > IDirectMusicContainer and almost completely (but fully working I believe > IDirectMusicLoader)... Nice! What would you say is the status of DMusic (70-80-90% complete?) > => oh and if somebody is interested in test programs I wrote & used and > some docs on dark sides of dmusic (written by myself ;)), mail me and > you'll get them in 24 hours ;) Shouldn't we get this into the tree somewhere? (either as comments in the code, or as documentation in the Devel Guide). Ditto for test program (not sure where it should go though...) > => and happy New Year everyone! Happy New Year to you too! -- Dimi.

20 years, 4 months

New registry key adding patch

by Zimler Attila

Hi, I made the regedit program able to add new registry key (however, the key does not appear until next run of regedit in the browser tree - as I consulted it with Dimitrie, it will be handled later). The diff is made against todays cvs tree (as 2003 december 31). Attila PS: Dimitrie: what is the next step to do? diff -r -d -c -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 2003-12-31 14:36:44.000000000 +0000 *************** *** 17,22 **** --- 17,25 ---- * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ + /* Modified by Attila ZIMLER <hijaszu(a)hlfslinux.hu> on 28th of dec 2003. + - New key adding is now supported. + */ #define WIN32_LEAN_AND_MEAN /* Exclude rarely-used stuff from Windows headers */ *************** *** 91,96 **** --- 94,129 ---- return FALSE; } + BOOL CreateKey(HKEY hKey) + { + LONG lRet; + HKEY retKey; + char* keyName = 0; + 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 */ + /* TODO: warning is issued because asprintf's implicit declaration, + I tried to declare it as + extern "C" ssize_t asprintf(char**, const char**, ...) + which is the format of this function, but it seems not helping. + Don't know why :( + */ + asprintf(&keyName, "new key"); + lRet = RegOpenKey(hKey, keyName, &retKey); + while (lRet == ERROR_SUCCESS) { + asprintf(&keyName, "new key %u", ++keyNum); + lRet = RegOpenKey(hKey, keyName, &retKey); + } + + lRet = RegCreateKey(hKey, keyName, &retKey); + + free(keyName); + return lRet == ERROR_SUCCESS; + } + BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName) { DWORD valueDataLen; diff -r -d -c -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 2003-12-31 14:38:34.000000000 +0000 *************** *** 469,474 **** --- 469,478 ---- case ID_EDIT_COPYKEYNAME: CopyKeyName(hWnd, _T("")); break; + case ID_EDIT_NEW_KEY: + if (CreateKey(hKey)) + RefreshListView(g_pChildWnd->hListWnd, hKeyRoot, keyPath); + break; case ID_REGISTRY_PRINTERSETUP: /*PRINTDLG pd;*/ /*PrintDlg(&pd);*/ diff -r -d -c -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 2003-12-31 14:39:57.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__ */

20 years, 4 months

Renaming registry keys...

by Robert van Herk

Hi! Does anybody have a C algorithm to rename a registry section using the Win32 API? I need such a thing for winecfg, but Win32 doesn't seem to have a RegKeyRename api-call... Grtz, Robert

20 years, 4 months

Just adding an entry in the.spec file makes somethin build?

by Joshua Walker

Are .spec files automahicly built? Adding an entry to the .spec file does what exactly? From my standpoint all it does is add an entry to the documentation thats generated by c2man.pl, but it's undocumentabale, not linked to anything, and just sits there. I'm assuming you *MUST* have a function, or a declration, or something the jive with the .spec file? On second thought, this is more of a functionallity question. Here's more on documentation... I wanted to say this after I finished documenting the API of a DLL, but it's more releivent here. Many people program open source for many reasons. I simply want to learn the Win32 API. I have no idea why, I guess I'm just cerious about how it works. As I am sitting here placing comments into code I am reminded of a short story in "The Hitchhiker's Guide to the Galaxy" In the story there was an alien who had immortility accidently placed upon him by way of a particle accelorator, a rubber band, and I think some tea... But I'm not too sure about that bit. Anyway he had a grand old time simply outliving the hell out of everyone. After a while he became biter an jaded, he needed something to do to bide his time and so he decided to insult the universe. The worst bit, and the part that he fought so hard to maintain, is that he decided to do it *Alphabectally* I feel much like this guy, I'm starting in advapi32.dll and methotcally working my way through it. At first I wanted to do an end-to-end API documentaion, but I'm hampered by things that arn't implmented yet. That's fine, I'll just do an end-to-end Wine API documentation instead. I do not have the skills to fill in code myself. I don't even have a test suite (Read:windows computer) to check myself against anyway. I have found that when I document the APIs, that the subs tend to stand out between the hyperlinks. It almost feels like they are saying "Look at me! Not only do I not fuction, but I can't get a lousy hyperlink either!" And so I think I have found another motivtion to do Open Source programming. Guilt. Yes, I am now panning to guilt people into impmentation. All those entries look soooo pretty it it wasn't for those ugly, black stubs in there. I would like to have the entire API in there, stubbed out, to simply enhance the guilt. But I shall just "do what's there" I just dispuse going through what I've written when I have an eppifiny of some sort. I have to do it again anyway as I need to link up some advapi32 calls to some ntdll calls. I just learnd that one was a front end to another... Anyway, I guess this is a rounds about way of saying this, but I'll just do what's there, and hopefully guilt others into implemtation ^_^ -Joshua P.S. If I find someone who has implemented something after I've gon through the DLL, only to find they didn't bother to make a simple documentation header for it.... Well, then I'd just be really sore....

20 years, 4 months

Docs

by Ivan Leo Murray-Smith

Hi list, I've noticed this  in getting.sgml, I've recently changed a few things in it, but there isn't a cvs.sgml file, should this warning go? Ivan.

20 years, 4 months

GetModuleFileName mysteries

by Ralf Juengling

I have some Windows code that uses GetModuleFileName in order to read some additional files at runtime that are expected at certain place relative to the executable. In Wine, GetModuleFileName doesn't work as intended, and I have trouble to track down the problem. I had to use winemaker's "wrap" option in order to work around initialization problems (C++ code). So the application, "memview.exe.so" is just a small wrapper which loads "memview.dll.so" via "LoadLibrary" and calls the dll's "WinMain". The startup script (a copy of wineapploader named "memview") determines the application's name to be "memview.exe" and thus executes "wine memview.exe". Under these circumstances, GetModulFileName yields "C:\WINDOWS\SYSTEM\memview.exe", which is not correct. If I alter the winapploader script so that wine gets called with "memview.exe.so" instead, GetModuleFileName yields "Z:\local\builts\phaeaco-20031216\src\memview\memview.exe", which is the correct path (but "memview.exe" doesn't exist). There is a second application which I built the very same way (i.e. using a small wrapper "phaeaco.exe.so" which loads the actual code contained in the DLL "phaeaco.dll.so"). This application also uses GetModuleFileName; here it always yields "C:\WINDOWS\SYSTEM\phaeaco.dll", no matter whether the application name given to wine by the wineapploader script is "phaeaco.exe" or "phaeaco.exe.so". This is a confusing picture. Could somebody point out what the expected result of GetModuleFileName is for this scenario (the full path to the dll, I guess) and how it comes about that it yields a path "C:\WINDOWS\SYSTEM\..."? I observed this with Wine-20031118, haven't tested more recent versions. Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

20 years, 4 months

Jump to page:

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 January 2004