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

Re: New registry key adding patch

by Dimitrie O. Paun

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. Please use uniffied diffs (diff -u) when submitting patches. > + /* try to find out a name for the newly create key. > + We try it max 100 times. */ > + sprintf(keyName, "new key"); You don't need this sprintf here > + 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; This condition is not right. We exit the loop when lRet != ERROR_SUCCESS which means we always return FALSE. -- Dimi.

Jan. 1, 2004

Re: unknwn.h: unknwn.idl

by Boaz Harrosh

Ove Kaaven wrote: >ons, 31.12.2003 kl. 17.48 skrev Robert Shearman: > > >>No. You should use cpp_quote. It may be necessary to disable stuff in the .h >>generated file which you can do with: >> >> > >You can't use cpp_quote inside an interface definition. The quoted text >would end up before the generated type, not inside. For interfaces, this >even has a good reason: the IDL compiler must emit both C and C++ >definitions for the interface, so the interface must be fully parsed >first, and then the definitions generated. MS considers this a feature, >as it lets you put typedefs and "import" statements inside the interface >definition, without harm to the generated header, as the embedded >typedefs and includes would still appear before the C/C++ definitions of >the interface. > >Even if cpp_quote statements could be parsed into the type instead of >emitted directly, where would the result go? In the C definition of the >interface? In the C++ definition? Both? > >Apparently, MS didn't solve that problem, so widl hasn't either. > > Exactly! Alexandre please permit me to remove unknwn.idl from idl list in include/Makefile.in. And send a patch for unknwn.h. Look at this file if ever it will change the half of windows will stop. All that is COM will. The unknwn.idl file itself should stay in CVS because it is needed by other idl files. Just the unknwn.h Generation should be disabled. Or should we go Ove way with a patch file and an add execution line to "make idl"? I think first option is better since that file will never change. (and my mother said to never say never :)) Free life Boaz

Jan. 1, 2004

RE: unknwn.h: unknwn.idl

by Ove Kaaven

ons, 31.12.2003 kl. 17.48 skrev Robert Shearman: > No. You should use cpp_quote. It may be necessary to disable stuff in the .h > generated file which you can do with: You can't use cpp_quote inside an interface definition. The quoted text would end up before the generated type, not inside. For interfaces, this even has a good reason: the IDL compiler must emit both C and C++ definitions for the interface, so the interface must be fully parsed first, and then the definitions generated. MS considers this a feature, as it lets you put typedefs and "import" statements inside the interface definition, without harm to the generated header, as the embedded typedefs and includes would still appear before the C/C++ definitions of the interface. Even if cpp_quote statements could be parsed into the type instead of emitted directly, where would the result go? In the C definition of the interface? In the C++ definition? Both? Apparently, MS didn't solve that problem, so widl hasn't either.

Jan. 1, 2004

Re: Windows dll replacement with Linux library

by Dimitrie O. Paun

On December 31, 2003 07:33 pm, Dan Timis wrote: > I don't understand how Windows dlls and Linux libraries link and how > functions are called. What am I missing? Please use winegcc to build the test app. It does a number of housekeeping tasks behing the scene that might help. -- Dimi.

Jan. 1, 2004

Re: GetModuleFileName mysteries

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > 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. It's not that easy, because system dlls have to be loaded from the system directory, so you need GetModuleFileName to return that. It's only for dlls loaded with a explicit path that you can try to return the actual path to the .so file. Also with dlls loaded directly by the Unix loader (which you probably need in C++) you don't have access to the original path at all. > 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. Thanks; I certainly enjoyed spending two weeks without touching a computer. I should do that more often <g> -- Alexandre Julliard julliard(a)winehq.com

Jan. 1, 2004

Windows dll replacement with Linux library

by Dan Timis

Sorry, I hit send by mistake. Here is the entire message. Hi, I wrote to the list a few weeks ago. I needed to support a USB device without changing the Windows dll that I have to use. I was trying to hack into wine to implement support for the USB device using CreateFile() and DeviceIoControl(). That was not a clean solution. The author of the Windows dll has agreed to support a mid level dll that would implement functions like USBDeviceOpen(), USBDeviceClose(), USBDeviceRead(), and USBDeviceWrite(). On Windows those would use CreateFile() and DeviceIoControl(), while on Linux they would use libusb calls. I followed the example from the winelib user guide, chapter 5 "Using Linux libraries as DLLs" As an example I will talk just about USBDeviceOpen(). Here it is how it is declared together with a proxy function: HANDLE WINAPI USBDeviceOpen(const DWORD in_dwIndex); HANDLE WINAPI USBDeviceOpenProxy(const DWORD in_dwIndex); This function opens a specific device from a specific manufacturer. If more than one device is connected, the index will specify which device to open. In the spec file I put: 101 stdcall USBDeviceOpen (long) USBDeviceOpenProxy I used winemaker, configure, make, and make install. Now I have "USBUtils.dll.so in /usr/lib/wine. I wrote a small test program. It has a WinMain function and it calls USBDeviceOpen. I used winemaker again and I am running the test application this way: # wine -- test.exe.so If I call USBDeviceOpenProxy (or any other proxy function), the test application links and runs correctly. I tested all functions and they work as expected. But, if I call USBDeviceOpen, the application does not link (undefined USBDeviceOpen). If I use the C compiler (instead of C++) the application links, but at runtime it does not find USBDeviceOpen. I don't understand how Windows dlls and Linux libraries link and how functions are called. What am I missing? I would appreciate any help. Dan Timis Muse Research, Inc.

Jan. 1, 2004

Re: unknwn.h: unknwn.idl

by Alexandre Julliard

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > "make idl" will make all of the idl files. I'm not sure why it is done this > way, but those files are only updated once in a blue moon anyway. Because building them automatically causes a lot of headaches when generating dependencies. I'll get around to fixing that someday, but as you noted these files don't change often so for now you need to rebuild them explicitly (that's also why the .h files are in CVS, even though they are generated files). -- Alexandre Julliard julliard(a)winehq.com

Jan. 1, 2004

Re: Missing exports?

by Alexandre Julliard

Tom <twickline(a)skybest.com> writes: > 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 ?? No. As already explained a number of times, adding stubs for new functions is just asking for trouble, since apps will now try to call the functions and die. Stubs should only be added if there's an app that requires them. 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. -- Alexandre Julliard julliard(a)winehq.com

Jan. 1, 2004

Windows dll replacement with Linux library

by Dan Timis

Hi, I wrote to the list a few weeks ago. I needed to support a USB device without changing the Windows dll that I have to use. I was trying to hack into wine to implement support for the USB device using CreateFile() and DeviceIoControl(). That was not a clean solution. The author of the Windows dll has agreed to support a mid level dll that would implement functions like USBDeviceOpen(), USBDeviceClose(), USBDeviceRead(), and USBDeviceWrite(). On Windows those would use CreateFile() and DeviceIoControl(), while on Linux they would use libusb calls. I followed the example from winelib user guide, chapter 5 "Using Linux libraries as DLLs" As an example I will talk just about USBDeviceOpen(). Here it is how it is declared together with a proxy function: HANDLE WINAPI USBDeviceOpen(const DWORD in_dwIndex); HANDLE WINAPI USBDeviceOpenProxy(const DWORD in_dwIndex); This function opens a specific device from a specific manufacturer. If more than one device connected In the spec file I put: 101 stdcall USBDeviceOpen (long) USBDeviceOpenProxy I used winemaker, configure, make, and make install. Now I have "USBUtils.dll.so in /

Jan. 1, 2004