I have an application(actually 4 apps) that uses 4 different serial devices. Each has been mapped properly and can be seen or used by the applications individually. However the apps do port enumeration to find the proper device to use. When a new device is enabled wine crashes HARD. The reason is wine is not locking a say com1 once it is in use and the new app starts scanning from com1 and can actually reopen the already in use port.This of course causes wine to lock up. This is super bad behavior. Does anyone have a suggestion for a work around to lock the port so it cannot be opened by another app?
And don't tell me this isn't a wine bug....it is.
COM ports are not getting locked
Ah! Thanks now that makes sense ... only winserver is opening the ports so of course it always has permission. Duh I should really have caught on to that by now. So the temporary solution is to remove devices from the registry(windows enumerates on the registry) as they are opened. If they are let go(closed), add them back. Perfect, thanks for the kick in the pants! That will work for sure. Even wine shouldn't enumerate a device that doesn't exist in the registry.
"man wine" Read the bit on WINEPREFIX.
Each wine prefix can have access to different devices. Device links are not stored in registry but in WINEPREFIX/dosdevices as a link to the device.
So stick the conflicting programs in different WINEPREFIX's with the only the devices they should be accessing.
The WINEPREFIX workaround does not help when program itself multi opens the same port due to poor coding.
Yes issue in wineserver needs fixing.
Each wine prefix can have access to different devices. Device links are not stored in registry but in WINEPREFIX/dosdevices as a link to the device.
So stick the conflicting programs in different WINEPREFIX's with the only the devices they should be accessing.
The WINEPREFIX workaround does not help when program itself multi opens the same port due to poor coding.
Yes issue in wineserver needs fixing.
So if each program is running under a separate instance of wine(using wineprefix) will they still be able to pass information to eachother and grab window handles? Each serial device is read by a daemon app that collects, decodes, then sends the data to the main application which displays it. Another issue is 2 of the devices use the same exact serial to usb chip set yet are different devices so being able to enumerate at least those two is necessary. It's more of a device locking conflict than an application conflict. It sounds like we might just be SOL until the wineserver is fixed, unless we can manage to do it in the windows apps themselves.
I've had to make custom video drivers(to get opengl to work), special udev rules(a vain attempt to statically map ports), change wines clock setting sanity check(yes the clock must be set by the gps), make custom linux daemons to do cleanup windows would normally do, custom launchers to prevent strange errors, run as root(yes it is a necessity for permissions sake and these devices will never see or be attached to any network So it is OK), and test about 8-10 window managers to get similar behavior to windows window focus and behavior(nothing is exact). So as you can imagine after 7 years I am not going to give up
.
It is especially important for aviation software to be very stable and it already is more so under wine/linux, but it is also important that everything works the same as in windows. So I put out there, to any wine developers, that are also into aviation I will gladly donate a copy of the application suite to anyone who can help with this last little stitch with the wineserver. I can't give you the gyroscope, gps, traffic radar, and live satellite weather feed, however it may be possible we could meet to test these. This is truly some of the best software for aviation out there and it would be so much better if it ran perfectly under linux. It's so close it's making me antsy.
I've had to make custom video drivers(to get opengl to work), special udev rules(a vain attempt to statically map ports), change wines clock setting sanity check(yes the clock must be set by the gps), make custom linux daemons to do cleanup windows would normally do, custom launchers to prevent strange errors, run as root(yes it is a necessity for permissions sake and these devices will never see or be attached to any network So it is OK), and test about 8-10 window managers to get similar behavior to windows window focus and behavior(nothing is exact). So as you can imagine after 7 years I am not going to give up
. It is especially important for aviation software to be very stable and it already is more so under wine/linux, but it is also important that everything works the same as in windows. So I put out there, to any wine developers, that are also into aviation I will gladly donate a copy of the application suite to anyone who can help with this last little stitch with the wineserver. I can't give you the gyroscope, gps, traffic radar, and live satellite weather feed, however it may be possible we could meet to test these. This is truly some of the best software for aviation out there and it would be so much better if it ran perfectly under linux. It's so close it's making me antsy.
Running as root in Linux for wine is not truly required. Posix file capabilities can set the extra bits wine needs to do everything without giving wine root powers.
Highly complex application. Network to Network can be used between Wine prefixs if the application supports.
Its looking more and more locking in wineserver is needing fixing to get this working.
There is the option of paying codeweavers to work on it. Outside a lot of peoples budgets. Its like the last option.
Depending on your coding skills lot of the wine developers are prepared to help ones wanting to learn how to fix problems.
Closest to exactly for focus is inside the virtual desktop. Yes another area in need of work.
Sounds of things you have been hacking around issues instead of fixing the errors in the wine code base. Cleanup bit not working as per windows in wine would be another bug in wine to fix.
Hacking around issue with wine is not exactly wise because one day it gets fixed then other problems appear caused by hack.
Highly complex application. Network to Network can be used between Wine prefixs if the application supports.
Its looking more and more locking in wineserver is needing fixing to get this working.
There is the option of paying codeweavers to work on it. Outside a lot of peoples budgets. Its like the last option.
Depending on your coding skills lot of the wine developers are prepared to help ones wanting to learn how to fix problems.
Closest to exactly for focus is inside the virtual desktop. Yes another area in need of work.
Sounds of things you have been hacking around issues instead of fixing the errors in the wine code base. Cleanup bit not working as per windows in wine would be another bug in wine to fix.
Hacking around issue with wine is not exactly wise because one day it gets fixed then other problems appear caused by hack.
