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

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