[Bug 46676] New: Serial port enumeration (get device description) on Mac OS/X 10.9, 10.13
https://bugs.winehq.org/show_bug.cgi?id=46676 Bug ID: 46676 Summary: Serial port enumeration (get device description) on Mac OS/X 10.9, 10.13 Product: Wine Version: 4.0 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: setupapi Assignee: wine-bugs(a)winehq.org Reporter: martin(a)hinner.info Created attachment 63628 --> https://bugs.winehq.org/attachment.cgi?id=63628 suspected problematic function Tested on: Mac OS/X 10.9, 10.13 WineBottler (Wine 1.8) works fine; Wine 4.0 (from .pkg) does not work Our application is trying to enumerate serial ports by using setupapi functions. I have not checked where exactly is the problem as debugging on OS/X is a bit difficult for me, however suspected function is attached (it's goal is to get device description). The affected apps are http://obdtester.com/ficom , http://obdtester.com/bimcom , http://obdtester.com/fcom ; I have tried to create symlink in dosdevices (required for WineBottler to get it working), one OS/X 10.13 my link got deleted everytime I ran the app; on OS/X 10.9 link persisted, but not possible to enumerate any serial port(s). I can provide login for download by personal e-mail (not to be disclosed). I have talked about this on wine mailing list a long time ago, it would be super easy if Wine-enabled application can have a way to load system native .so to talk directly to the host system, I have many examples of device drivers that would be super easy to implement. FYI I have already written "winegate.dll.so" which solves this real world problem, but it was rejected for submission to Wine because of "Wine must be 100% transparent" ideology. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- Serial ports currently aren't enumerated in setupapi, yes. I think they certainly could be, though. I'd try taking a stab at it myself, but I don't have any serial hardware to test with. Looking at the discussion mentioned (https://www.winehq.org/pipermail/wine-devel/2009-February/073133.html), I'm a little bothered by the suggested uses of wine_dlopen(); it certainly can't be loaded the normal way, but surely the proper way is to compile as a winelib application, and thus link to libwine directly? Or is this also infeasible for some reason? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #2 from Martin Hinner <martin(a)hinner.info> --- Re https://www.winehq.org/pipermail/wine-devel/2009-February/073133.html Recompilation using libwine is not feasible as our code is quite MSVC specific, also including some assembly language. We should also consider MFC recompilation legality. Simply Linux/Mac userbase is so small that we cannot spend time on this. On the other hand, modifying single class that does serial port enumeration and communication is VERY simple. I understand we can make "serial driver DLL" and very simple .dll.so that would do the same job on Unix/Wine, however this is not very practical as we would have to maintain library dependencies, develop different versions (one for BSD, one for Linux, one for Mac). On the other hand detecting host OS type is fairly simple by trying to dlopen a few libraries/functions (if they fail we can always fallback to Windows serial ports and trust Wine it is completely supported like it is now on Linux). It is all POSIX, so Unix part would be simply just a simple library with a few system dependent tweaks. It would also make bluetooth connection possible, which is AFAIK totally impossible with wine (We would simply let user connect rfcomm device from the host system and then use it using open()/read()/write()/select() acquired from wine_dlopen). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #3 from Martin Hinner <martin(a)hinner.info> --- Re hardware, I think any of these work on OS/X https://www.ebay.com/sch/i.html?_from=R40&_nkw=usb+to+serial&_sacat=0 (cost about $1 incl. shipping) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Martin Hinner from comment #2)
Re https://www.winehq.org/pipermail/wine-devel/2009-February/073133.html
Recompilation using libwine is not feasible as our code is quite MSVC specific, also including some assembly language. We should also consider MFC recompilation legality. Simply Linux/Mac userbase is so small that we cannot spend time on this.
On the other hand, modifying single class that does serial port enumeration and communication is VERY simple.
I understand we can make "serial driver DLL" and very simple .dll.so that would do the same job on Unix/Wine, however this is not very practical as we would have to maintain library dependencies, develop different versions (one for BSD, one for Linux, one for Mac). On the other hand detecting host OS type is fairly simple by trying to dlopen a few libraries/functions (if they fail we can always fallback to Windows serial ports and trust Wine it is completely supported like it is now on Linux). It is all POSIX, so Unix part would be simply just a simple library with a few system dependent tweaks.
It would also make bluetooth connection possible, which is AFAIK totally impossible with wine (We would simply let user connect rfcomm device from the host system and then use it using open()/read()/write()/select() acquired from wine_dlopen).
You should be able to configure the device as a serial port in the registry, even if it's not enumerated by setupapi, cf. https://wiki.winehq.org/Wine_User%27s_Guide#Serial_and_Parallel_Ports Providing a generic way to call host functions doesn't make much sense, because the calling conventions are usually not compatible, and in general the functions wouldn't be compatible across Unix platforms either. It would only work for very simple hacks, it's not the general mechanism that it looks like. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #5 from Martin Hinner <martin(a)hinner.info> --- ad registry mod: I remember some Wine version on customer's OS/X even deleted the symlinks, so this did not work (or the symlinks somehow disappeared each time I started Wine). On my OS/X ~/.wine/dosdevices/ symlinks are persistent, but not functional in the app. What makes me curious is why Wine(bottler) 1.8 works ... (I have not checked source code changes) ad wine_dlopen: I know about calling convention differences, different structures/arguments/etc, and other caveats as well. Despite of this I still think such feature would be very useful. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Martin Hinner from comment #5)
ad registry mod: I remember some Wine version on customer's OS/X even deleted the symlinks, so this did not work (or the symlinks somehow disappeared each time I started Wine).
Yes, the symlinks are managed automatically now, that's why you have to set the registry entries instead.
ad wine_dlopen: I know about calling convention differences, different structures/arguments/etc, and other caveats as well. Despite of this I still think such feature would be very useful.
Well, you are pretty much the only one who's asked for it in 20 years, so it's not clear that it would be all that useful. So far all potential use cases seem to have better alternatives. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 --- Comment #7 from Martin Hinner <martin(a)hinner.info> --- About registry- would it be possible at least to auto-detect OS/X serial devices correctly ? Serial ports that I am interested in are /dev/cu.usbmodem* (e.g. cu.usbmodem14201). I can test it on a real hardware if such change gets compiled to a downloadable .pkg , I have no tools/time to compile for OS/X. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Serial port enumeration |mountmgr does not enumerate |(get device description) on |serial ports on Mac OS |Mac OS/X 10.9, 10.13 | Component|setupapi |mountmgr.sys --- Comment #8 from Zebediah Figura <z.figura12(a)gmail.com> --- This is partly bug 10051, but there's also the separate problem that we don't enumerate serial ports in mountmgr for Mac OS, so let's make this about that part. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46676 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|mountmgr.sys |serial -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla