Re: WINEGATE.DLL: Wine gateway to native Unix libraries
On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget fgou...@free.fr wrote: From what I understand, they're not accessible to full win32 apps. FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any Win32 application that knows about it. Just LoadLibrary()+GetProcAddress(). This is really nice end of our conversation, giving new dimension to all sharp statements (hack, not going into wine, etc) :-). Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...), so there is no need for other argumentation. I have already given up. Regarding to maintenance of linux library, I meant to have different BINARY versions (because of other dependencies), not source code. And finally regarding putting WINEGATE to some wiki: Feel free to do it, consider it public domain. But I think the point of this library was that if it is compiled WITH wine package, it would smoothly solve dependency problems (i.e. no need to carry separate WINEGATE-libcX-OSy-platformZ libraries). Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
On Tue, Feb 17, 2009 at 3:34 PM, Dan Kegel d...@kegel.com wrote: On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner mar...@hinner.info wrote: Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...), Wait, what can winegate do that hdll = LoadLibraryA(libwine.dll); wine_dlopen = GetProcAdress(hdll, wine_dlopen); wine_dlsym = GetProcAdress(hdll, wine_dlsym); wine_dlclose = GetProcAdress(hdll, wine_dlclose); can't do? You really shouldn't need to ship winelib dlls. Can't you compile winegate as a real windows DLL that just knows about these special wine functions? The above doesn't work ... LoadLibraryA fails (returns NULL). Tested both on fresh install from a package + latest source code build. M.
Wine viruses
Hi, I will start one more hot discussion. Sorry if it was discussed earlier, I am not regular reader of this mailing-list. I tried to search google, found several discussions, but no real result: http://www.linux.com/feature/42031 http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 wine-devel mailing list google results The problem is that some (almost all?) distributions simply execute .exe file when you click on it. I was amazed when testing JTAGTest on Linux! This is in my opinion quite big issue as ordinary users do not have problem clicking on New folder.exe on their flashdisk etc. It's good that wine is so compatible that it runs even viruses, but I think there should be some (optional) protection. The biggest problem seem to be removable media, in many distributions mounted under /mnt or /media. Please think about this twice before writing problem is in Microsoft not in Wine, it's not a bug but feature, etc. It's too childish IMO. - What about creating a configurable list of directories, where wine would first ask if you really want to execute the program? It would be up to distribution what is set-up by default. - It's long time I have been interested in viruses, but I think that 90% of most common virus infected/trojan .exe files can be pretty easily identified. Almost every modern virus is trying to connect to the internet either by opening socket or using few standard DLL functions. What about adding some checks to Wine that would check the calling function code sample against some small database to see if this is a virus and ask user? Or adding some API functions to allow someone to write such program? I have done quite a lot of work with PE loading and code modification and I think it could be moved to level when it works without crashing anything. I understand, that none of this is system solution. But are anti-viruses system solution? They solve real world problem. Regarding API I have mentioned above I mean some hookdll() function that would re-direct GetProcAddress() or PE loader for defined functions, i.e.: http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Obviously this would have to be global for wine (libwine.so?), not as a PE exported API function. Pre-loaded antivirus would be able to hook Winsock functions + some other important stuff and then check if the binary code is not on the list. Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
Detlef,
On Sun, Feb 15, 2009 at 12:50 PM, Detlef Riekenberg wine@web.de wrote:
Just use this infos:
hdll = LoadLibraryA(libwine.dll);
wine_dlopen = GetProcAdress(hdll, wine_dlopen);
wine_dlsym = GetProcAdress(hdll, wine_dlsym);
wine_dlclose = GetProcAdress(hdll, wine_dlclose);
The LoadLibraryA call does not work for me. Tried with many names
(wine,libwine, etc) and wine is according to strace always trying to
open /usr/lib/wine/{lib}libwine.dll.so which is not obviously present.
M.
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg wine@web.de wrote: On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote: Hi Martin. Thanks for your interest in Wine. I read your Mail, and my first impresion was: not needed After downloading winegate.tar.gz and reading the source: winegate is a nice Idea, but it's useless. Why? - Your proxy code is not portable. I am aware of this, it was proof-of-concept, I am definitely NOT against using wine_dlopen or add #ifdefs to make it portable (for systems not having dlfcn.h). - It's already present in Wine: libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c I saw it, but I don't understand how is it exported to the Win32 world, i.e. how do I import these using GetProcAddress() Win32 API ? find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not reveal anything except winegate.dll :-). Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
Dan, On Sat, Feb 14, 2009 at 7:44 AM, Dan Kegel d...@kegel.com wrote: I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative. I think wine needs some universal library so as there is not 20 other ISV-specific solutions... If wine-team decides not to include this (or similar .dll) in the Wine package, we'll just redistribute it with the application, but I think there is need for such library. I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do. btw nice name, but it pulls up 7 million hits for me, not sure what you mean by google doesn't reveal any other uses of the name. :-))) I was searching for winegate.dll, not just plain winegate. I meant that there will likely be no collision with other .DLL. Now it finds my post + some garbage. Google is damn fast. Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
Ben, On Sat, Feb 14, 2009 at 7:10 AM, Ben Klein shackl...@gmail.com wrote: 2009/2/14 Martin Hinner mar...@hinner.info: Wine is (or has been) working on a driver system to handle native Windows USB device drivers via libusb, for things like printers and scanners where there are no Linux-native drivers. This is a better solution. Yes, but it is only for some devices. I will give you again one example I was mentioning: FTD2XX.DLL driver from FTDI. They have versions for many systems, but these behave a little bit different way. Tell me how would you solve this problem. Write a complicated libftd2xx.dll.so wrapper to maintain compatibility ? For how many applications would it work? There are thousands of similar problems between Win32-Linux world. Do you think that ISVs will find budget for this to support Linux or just not do it? All this is what WINEGATE.DLL sovles with minimum possible effort. You simply create class CWin32Driver CLinuxWineDriver and you're done. Only when a suitable native Linux library already exists, correct? There aren't many cases of this, from what I understand. I think it's more cases than you think. I can give a lot of examples, but that would be spamming of this mailing-list. Just one more thing, I tried one of our applications using HID-usb device. Does not work under Wine. I have no idea why, it's probably possible to fix the problem (in wine), but this clearly shows that world is not always ideal. Why not use winelib for these cases if *nix support is important enough to modify the source so it works nicer in Wine? Because sometimes you don't get enough customers to get paid for native Linux version and it's quite complicated to port even mid-sized projects using winelib. For example try to compile MFC ... Given that for your system to work there has to be a Linux-native library for winegate to hook into, the effort involved in porting to Linux via winelib would likely be equal. I disagree... I am not pushing on WINEGATE.DLL inclusion in Wine package. If it's not included, we'll include it in our installers and problem is solved. But I think other developers need such library to make their apps. working under Wine and it's much better to have one standard and well documented library than 10 or 20 proprietary solutions. I understand it is not clean solution, but world is not perfect. If it's included, I am willing to help with maintenance and write some documentation. My feeling is that Linux desperately needs applications that currently run only on Windows. Companies will not use Linux if they cannot run their applications on it. It's like binary drivers. They are bad, but better than nothing. In an ideal world there would be no need for Wine anyway :-). Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
VItaliy, On Sun, Feb 15, 2009 at 3:21 AM, Vitaliy Margolen wine-de...@kievinfo.com wrote: Depending on what you need to do it might be a good thing or might be a complete no-go. Remember that Wine has an additional layer on top of system. If you bypass it, you can potentially create lots and lots of problems. I understand this. For ourselves, it is intended to gain access to native Linux drivers. It would be nightmare to try to create wine dll that would act as a wrapper between virgin Win32 app and Linux driver. For example, handles, synchronization, GUI, messages, d3d, ddraw (and most other things) depend on those extra layers. You won't be able to use them together without major risk of instability. Eg. you can't pass fd to ReadFile(). Nor can you block on read() and expect message processing in the same thread. Not saying it can't be done. It just needs to be coded with consideration of Wine inerworkings. I understand this and in my opinion (if there will be any official WINEGATE.DLL) there should be documentation mentioning things like this one. In addition there should be also functions to convert file handles between posix wine handles + path conversion tool (but we do not need any of these, I mean they migh be useful to someone else). What I want to say, what you did is just an API that doesn't solve anything on its own. Anything using it will be as complex as writing winelib application. Or will have to be expanded to properly fit into Wine. Yes, the WINEGATE.DLL is not solving any problem on its own, it just simplifies porting process. Using it is NOT as complex as writing winelib application, because you have to write only Linux-dependent parts, the rest of application can remain untouched. Please note that to my knowledge it is not even legal to create winelib application if it is using some libraries such as MFC (depends on version, license, etc.). I think I have clearly explained in my previous posts what this library should do and what would advantages of having it be. Now I would like to hear if you (wine people) accept such solution and include it in some way in Wine distribution. Currently I understand there is no interest. I don't want to be rude, but I have better things to do than propagandize my solution. We can live without such library in Wine, it would just require us to maintain separate libraries for different libc or wine versions. Having it in wine distribution would solve this problem smoothly, reducing our task only to maintain native Linux shared lib for hardware access. If anything changes in your position, let me know, I am willing to help with it. Martin
WINEGATE.DLL: Wine gateway to native Unix libraries
Hello, I have created a small library to allow Win32 applications running under Wine to load native Unix shared libraries (.so). First (one-hour hack) version is available at http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider inclusion in WINE tree (dll/ directory). Please note that Makefile.in as well as configure scripts will likely need some changes. Purpose of this Wine DLL is to allow Windows applications to use directly Unix library functions. This is useful for example for applications which talk to specific drivers and it's not efficient/possible to create system native DLL for such driver or library. Win32 app. vendor is required only to detect execution under Wine and load proper native library. WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them. This library should export all functions that are required to load additional libraries and detect type version of system we're running on. I believe that NO additional functions are required as you can always import uname() and call it to obtain more information on the running system, so dlopen/dlsym/dlclose is enough. Maybe some 'getwineversion' function should be included - waiting for your comments. I am sure there will be a lot of people arguing that Win32 application SHOULD NOT be modified to behave differently in Wine. I agree that in most cases it's better to fix Wine than applications, but there are real world problems that cannot be efficiently solved outside the application. One good example is when Win32 app has to talk to custom hardware. In many cases there are native Linux drivers that have different API/etc and it is very very difficult to create wrapper library between Windows-style and Linux/Unix-style drivers. In such cases it's much easier to modify source code of Windows app to use either Linux or Windows drivers/DLLs/etc. Example how to use WINEGATE.DLL is in winesupp.zip (please note this is quite silly example). If you want to see real world application which uses this library, go to http://www.jtagtest.com I have chosen name Wingate because google did not reveal any other use of such name and I think it fits it's purpose. Feel free to suggest any other names or just rename the library. Martin
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
Hi, On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein shackl...@gmail.com wrote: 2009/2/14 Martin Hinner mar...@hinner.info: Purpose of this Wine DLL is to allow Windows applications to use directly Unix library functions. This is useful for example for applications which talk to specific drivers and it's not efficient/possible to create system native DLL for such driver or library. Win32 app. vendor is required only to detect execution under Wine and load proper native library. Windows apps don't call *nix libraries directly as is, so I'm not sure I understand the purpose here. I can see it could potentially be useful for porting apps using winelib, but I don't see how it can be useful for full win32 apps precompiled for Windows systems. It is very useful for win32 apps in case you are dealing with hardware or some specific stuff. I am not talking about using this to fix wine bugs (i.e. creating a broken app). Think about application that is used for some industrial control, uses some USB device with vendor-specific driver (no hid, CDC, mass storage, etc). If you want to get it working on Linux, you have to either create complicated wrapper for your Windows drivers (which is in many cases impossible, btw) or you can use native linux driver, libusb, etc. Another good example is automotive diagnostics. And another example is FTDI FTD2xx drivers (although they have tried to maintain compatibility between Win/Linux/Mac versions, you have to use different routines on each system). All this is what WINEGATE.DLL sovles with minimum possible effort. You simply create class CWin32Driver CLinuxWineDriver and you're done. I agree that in most cases it's better to fix Wine than applications, but there are real world problems that cannot be efficiently solved outside the application. One good example is when Win32 app has to talk to custom hardware. In many cases there are native Linux drivers that have different API/etc and it is very very difficult to create wrapper library between Windows-style and Linux/Unix-style drivers. In such cases it's much easier to modify source code of Windows app to use either Linux or Windows drivers/DLLs/etc. Why not use winelib for these cases if *nix support is important enough to modify the source so it works nicer in Wine? Because sometimes you don't get enough customers to get paid for native Linux version and it's quite complicated to port even mid-sized projects using winelib. For example try to compile MFC ... Martin
First steps to make Win32 app running under Wine
Hi, I am solving problem how to get one Win32 app (for which I have source code) running under Wine. The biggest issue is drivers and ioctls. Linux has driver support for what we need and provides similar ioctls for some stuff, but it differs from Windows. The difference is *so big* that I would prefer to modify our source code to use different pieces of code when it detects Wine. I understand, that this is *against* Wine policy and generally should not be used. But writing built-in replacement for some DLLs (hack Linux-style drivers into Windows-style) would be a nightmare, so having small mods to Win code would be much easier. I am not talking about generic functions, but about specific drivers/etc. Imagine this: Under windows you get usb driver with some ioctl-based interface, sometimes with DLL or without it (vendor provides only .lib file that gets statically linked). Under Linux there is libusb used. Difference between these two ways of driver implementation is *huge* and making libusb driver compatible with Win32 driver is almost impossible (in Win you have a real file handle, under libusb only pointer, etc.). It would greatly help for this case to be able to: - detect wine and platform from Win32 app (.exe) - load native Linux library and perform ioctls (ioctl(2), not Windows IOCTL!) on file handles - get somehow access to files in Linux filesystem (i.e. in /dev) This would allow to easily modify our source code in a few places (i.e. hardware routines) and get it quickly running under Linux. I can do all above by writing some built-in dll that would work just for my case, but I think *maybe* it's worth it to provide some generic interface in Wine?? Martin
Re: First steps to make Win32 app running under Wine
On 3/20/08, Marcus Meissner [EMAIL PROTECTED] wrote: Best bet is to just check for the registry key HKLM\Software\Wine I know also other methods, this is not a problem, I just wanted to ask if it's possible to get some official wine api for all this stuff. - load native Linux library and perform ioctls (ioctl(2), not Windows IOCTL!) on file handles Needs code in your application, but is technically possible. I know, the question is again about getting this officially into wine so as I don't have to make my own built-in .dll.so - get somehow access to files in Linux filesystem (i.e. in /dev) Same as above. No need for any specific code if you map Z: to / for instance. And if user does not? It would be nice to do _wine_open(/dev/something, O_RDWR) from my app. This would allow to easily modify our source code in a few places (i.e. hardware routines) and get it quickly running under Linux. I can do all above by writing some built-in dll that would work just for my case, but I think *maybe* it's worth it to provide some generic interface in Wine?? Hmm. We might be able to do this via msvcrt ioctl perhaps? No idea. IMHO it would be nice to have standard wineapp.dll.so that would work as a proxy between posix functions for applications that are aware about Wine. Such DLL would be a great helper! In fact I would need only dlopen() and dlsym(), maybe also uname() :-). This library could be loaded from Win32 app using LoadModule(..) on-demand. Martin
Re: Getting apps running under Wine
Hi, Please open a bug at our bugzilla (bugs.winehq.org). Attaching screenshots of the problem would help. We discourage you from working around Wine bugs, because if we fix the bug, we'll break your app in the process. Better to fix Wine. I 100% agree, but I wasn't sure if wine team is willing/able to help with this. Will do. 2) Windows drivers. We use DLL that depends on some Win32 drivers. Linux driver is available with similar API, so it's not a big problem to change our application to use Linux library. I understand that clearest way how to solve this problem is to make .dll.so file, but it's quite complicated for this particular application and I would prefer much more to add few if conditions to our Windows code that would recognize Wine under Linux and load native .so file (not .dll.so!). Is this possible? How to deal with different calling conventions between gcc and Visual C++ 2003 ? I'm not sure what you mean by different calling conventions; gcc supports the __stdcall convention, at least, and VC++ supports __cdecl. If you're using __fastcall you'll need to change it to one of the others, I think. Unfortunately I cannot change calling convention for one of DLLs as it's closed-source 3rd party file. As far as detecting Wine, again we prefer you don't. Would it be any great problem to ship a Linux version that called the Linux drivers, and a Windows version that called the Windows drivers? Having two versions of Win32 executable is IMHO not very practical, as 99% of the code would be same for both applications. The original question was about loading Linux .so files directly from .exe. How do we load (dlopen, dlsym) a .so library from .exe running under Wine ? This would solve our problem. Martin
Getting apps running under Wine
Hello, I would like to run some of our (win32-based) applications under Linux using Wine. At this time it is only for my personal use, but maybe someday some of our users will like to have it on Linux like me. I have managed to get all of them running, showing at least first dialog/window. But there are some problems: 1) User interface stuff. We are using dialogs (MFC CDialog) that have non-default font size (i.e. Times New Roman, 12 ). The font is displayed correctly under Wine, but dialog window has wrong size (it's smaller and some parts of dialog, mainly buttons at bottom, are not visible). I can send more info on this. How to solve this problem (other way than detecting Wine and resizing window manually) ? 2) Windows drivers. We use DLL that depends on some Win32 drivers. Linux driver is available with similar API, so it's not a big problem to change our application to use Linux library. I understand that clearest way how to solve this problem is to make .dll.so file, but it's quite complicated for this particular application and I would prefer much more to add few if conditions to our Windows code that would recognize Wine under Linux and load native .so file (not .dll.so!). Is this possible? How to deal with different calling conventions between gcc and Visual C++ 2003 ? 3) Windows service. We use a windows NT service (which can easily be ported to Linux,btw), an application communicates with the service using named pipe. Is it possible to communicate from wined application with some Linux program using technique other than TCP or Unix socket ? If no - is it possible to open Unix socket from our win app ? -- Martin Hinner http://martin.hinner.info http://www.auto-diagnostics.info
