Apologies if this is slightly OT.
I have the task of porting a Windows application to Linux. Since the
build environment (Borland C++ Builder) is highly windows-centric,
Wine is my only option short of a major rewrite. I will have no
problems with the regular GUI stuff, however, I need to access special
hardware devices (unsupported by Wine) on the Linux system via ioctl
and network sockets.
My question: How can I find a way "around" Wine, accessing resources
on the host running Wine? Are there special include files and service
DLLs available in Wine for this?
Thanks,
Chris
Porting Windows app to Linux: How to access Linux devices?
Number 1 wine applications really are running as linux/what ever platform they are on applications.
You will notice in virtual driver bits of wine. They are part wine code and part Linux code. Same is valid to do inside dll.so or exe.so created using wine.
You have a few options. Number 1 added a new virtual drivers providing hardware threw to wine so application so application exe will work on wine without needed to rebuild it.
Embed code linux code in the application like what is done in Linux.
Also be aware some network issues can be simple lack of permissions for wine to perform the task. Ie using the Linux calls will still fail if its lack of permissions.
Wine really does not try to do anything special. Since providing more ways really does not solve the lack of X feature problem in Wine to run non altered exe's.
You will notice in virtual driver bits of wine. They are part wine code and part Linux code. Same is valid to do inside dll.so or exe.so created using wine.
You have a few options. Number 1 added a new virtual drivers providing hardware threw to wine so application so application exe will work on wine without needed to rebuild it.
Embed code linux code in the application like what is done in Linux.
Also be aware some network issues can be simple lack of permissions for wine to perform the task. Ie using the Linux calls will still fail if its lack of permissions.
Wine really does not try to do anything special. Since providing more ways really does not solve the lack of X feature problem in Wine to run non altered exe's.
Thanks for the fast reply. Do you (or anybody) know of any examples where this has been done? I would like to do a rebuild with the Linux code right in the executable but I am really unsure how that would work in detail. Of course I'd need the kernel headers etc. on the Windows build environment but how about linking, calling conventions etc.? Remember it's not a GNU compiler I am working with.
First of all what are you trying to archive? Winelib app can't be run standalone. It can only be started under Wine. And you have to compile winelib with Wine tool chain.chrislpnt wrote:Thanks for the fast reply. Do you (or anybody) know of any examples where this has been done? I would like to do a rebuild with the Linux code right in the executable but I am really unsure how that would work in detail. Of course I'd need the kernel headers etc. on the Windows build environment but how about linking, calling conventions etc.? Remember it's not a GNU compiler I am working with.
If you want to access devices under Linux you better read documentation for that particular device/driver you are accessing. Wine won't help you there, it doesn't talk to devices directly and does not support device drivers.
As far as building this on not Linux env - it most likely won't work. GNU and other compiler produced code is not guaranteed to be ABI compatible. And usually it's not. You have to use the same tool chain, headers, libraries. Besides what's the use if you compile it outside Linux?
The application's GUI uses Borland's VCL library so that it can't be easily ported natively. I have tested this part under Wine, though, and it runs fine. If all the I/O the application required was usual, Wine-supported stuff (file and network access, etc.) I would be done here and could use the same binary. However, some of the I/O has to come from a driver that is not supported in Wine. The hardware works perfectly under Linux but obviously has a different API than in Windows. So, I have two elements:First of all what are you trying to archive?
- Windows GUI code running under Wine
- Linux drivers resp. modules supporting my hardware. They can be used via IOCTL and network socket calls.
I am trying to "marry" these two and am looking for the best method. Certainly the cleanest way would be to write a device driver for Wine but I was wondering if there was an easier way to interface to the Linux host from a Windows application running under Wine.
What api is application using to talk to the device.
Some cases applications use particular internal .dll's to talk devices.
From that case its building a layer that translates the windows calls to Linux calls. Can be done inside a dll.so in wine.
When deal with linking to devices there is no simple way unless you are lucky enough to be using serial or something wine already support.
.dll.so files of wine are permitted to be hybrid code. Ie windows calls provided to the application linux calls done inside.
Borland code kind cuts out just merging linux commands into the application so little more sneaky method need.
Another option is running a Linux program from wine. Also messy.
Hacky ways like what I suggested could never make it into mainline wine.
This is the other consideration coded so the device you are dealing with appears as a virtual device does stand a chance of going mainline and if other people are using other programs that interface with the same device more programmers to help keeping it working.
There is no clear black or white correct answer here. Part comes down to how long you need to keep this program working for. Is it a short term patch until it can be replaced. Or will the program be around for ages.
Some cases applications use particular internal .dll's to talk devices.
From that case its building a layer that translates the windows calls to Linux calls. Can be done inside a dll.so in wine.
When deal with linking to devices there is no simple way unless you are lucky enough to be using serial or something wine already support.
.dll.so files of wine are permitted to be hybrid code. Ie windows calls provided to the application linux calls done inside.
Borland code kind cuts out just merging linux commands into the application so little more sneaky method need.
Another option is running a Linux program from wine. Also messy.
Hacky ways like what I suggested could never make it into mainline wine.
This is the other consideration coded so the device you are dealing with appears as a virtual device does stand a chance of going mainline and if other people are using other programs that interface with the same device more programmers to help keeping it working.
There is no clear black or white correct answer here. Part comes down to how long you need to keep this program working for. Is it a short term patch until it can be replaced. Or will the program be around for ages.
-
Peter L Jones
Porting Windows app to Linux: How to access Linux devices?
Hi,
You could try taking a look at something like the wineasio code.
Whilst this isn't a device driver as such, it does demonstrate how to marry the
WINE and Linux worlds together (one way).
http://sf.net/projects/wineasio
(I'm only caretaking the project, really...)
-- Peter
chrislpnt wrote:
You could try taking a look at something like the wineasio code.
Whilst this isn't a device driver as such, it does demonstrate how to marry the
WINE and Linux worlds together (one way).
http://sf.net/projects/wineasio
(I'm only caretaking the project, really...)
-- Peter
chrislpnt wrote:
The application's GUI uses Borland's VCL library so that it can't be easily ported natively. I have tested this part under Wine, though, and it runs fine. If all the I/O the application required was usual, Wine-supported stuff (file and network access, etc.) I would be done here and could use the same binary. However, some of the I/O has to come from a driver that is not supported in Wine. The hardware works perfectly under Linux but obviously has a different API than in Windows. So, I have two elements:First of all what are you trying to archive?
- Windows GUI code running under Wine
- Linux drivers resp. modules supporting my hardware. They can be used via IOCTL and network socket calls.
I am trying to "marry" these two and am looking for the best method. Certainly the cleanest way would be to write a device driver for Wine but I was wondering if there was an easier way to interface to the Linux host from a Windows application running under Wine.
