[Bug 54314] New: my eprom programmer software can't recognize the hardware anymore.
https://bugs.winehq.org/show_bug.cgi?id=54314 Bug ID: 54314 Summary: my eprom programmer software can't recognize the hardware anymore. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: jacek.zmudzki(a)gmail.com Distribution: --- I used WINE for a long Time to program EPROMS with my Parallel-Port bases Programmer: http://www.conitec.net/english/galep4.php After an Update to Ubuntu 22.04 (with WINE 6.0.3) the Software https://appdb.winehq.org/objectManager.php?sClass=application&iId=2240 can't access the hardware anymore. I used the Runners from Lutris to investigate further: It seems that the Last Wine Version that works is WINE 5.4. -- 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=54314 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.0.3 Keywords| |regression Component|kernel32 |-unknown Summary|my eprom programmer |Conitec GALEP-4 EPROM |software can't recognize |programmer software can't |the hardware anymore. |recognize the hardware -- 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=54314 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- Please run a regression test: https://wiki.winehq.org/Regression_Testing -- 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=54314 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware CC| |alexhenrie24(a)gmail.com --- Comment #2 from Alex Henrie <alexhenrie24(a)gmail.com> --- Is it possible to reproduce the problem with a disconnected parallel port or a loopback adapter, or do you have to have the programmer? -- 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=54314 --- Comment #3 from Jacek Zmudzki <jacek.zmudzki(a)gmail.com> --- (In reply to Austin English from comment #1)
Please run a regression test: https://wiki.winehq.org/Regression_Testing
d637640f9af4ccfb6639361fc548d4bbeaafeb6f is the first bad commit commit d637640f9af4ccfb6639361fc548d4bbeaafeb6f Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Mar 26 16:49:17 2020 +0100 krnl386: Get rid of DOS parallel port I/O support. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> configure | 35 ----- configure.ac | 12 -- dlls/krnl386.exe16/ioports.c | 318 ------------------------------------------- include/config.h.in | 3 - 4 files changed, 368 deletions(-) -- 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=54314 --- Comment #4 from Jacek Zmudzki <jacek.zmudzki(a)gmail.com> --- (In reply to Alex Henrie from comment #2)
Is it possible to reproduce the problem with a disconnected parallel port or a loopback adapter, or do you have to have the programmer?
As far as I know you have to have the programmer -- 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=54314 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d637640f9af4ccfb6639361fc54 | |8d4bbeaafeb6f --- Comment #5 from Alex Henrie <alexhenrie24(a)gmail.com> --- Great job on the regression test! -- 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=54314 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- This would need to be reimplemented using an NT driver. In the meantime I'm afraid the only solution is to stick to an older Wine version. -- 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=54314 --- Comment #7 from Alex Henrie <alexhenrie24(a)gmail.com> --- As a workaround, you can try running the program with direct I/O access, such as with https://gitlab.com/alexhenrie/ioperm -- 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=54314 --- Comment #8 from Jacek Zmudzki <jacek.zmudzki(a)gmail.com> --- (In reply to Alexandre Julliard from comment #6)
This would need to be reimplemented using an NT driver. In the meantime I'm afraid the only solution is to stick to an older Wine version.
Does someone know why DOS parallel port I/O was removed? It was a great way to keep old Hardware working... -- 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=54314 --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Jacek Zmudzki from comment #8)
(In reply to Alexandre Julliard from comment #6)
This would need to be reimplemented using an NT driver. In the meantime I'm afraid the only solution is to stick to an older Wine version.
Does someone know why DOS parallel port I/O was removed? It was a great way to keep old Hardware working...
It cannot be supported with the new PE architecture (or rather, the amount of work needed to keep it working would probably be more than reimplementing it properly). -- 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=54314 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |medasaro(a)comcast.net --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> --- *** Bug 54520 has been marked as a duplicate of this bug. *** -- 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=54314 --- Comment #11 from Matthew D'Asaro <medasaro(a)comcast.net> --- This is a real shame we can't support DOS parallel port I/O anymore. There is a LOT of obscure hardware out there that uses parallel port interfaces, including items that are still being used in production at my day job. Support on modern versions of Windows isn't good either, leaving VMs and Wine was one of the only ways of making this work on modern hardware. Wine has the advantage of less / more consistent latency than a VM. -- 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=54314 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #12 from Zeb Figura <z.figura12(a)gmail.com> --- We can support it, but it needs to be rewritten. -- 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=54314 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.conitec.net/hard | |ware/down/G32setup_117.exe Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #13 from Alex Henrie <alexhenrie24(a)gmail.com> --- I got a GALEP-4 programmer and I got it working in Wine 8.21. Here's what I did: 1. Move or delete ~/.wine 2. Run `WINEARCH=win32 wine winecfg` 3. Set the Windows version to Windows 98 4. Run `wine G32setup_117.exe` 5. Run `ioperm wine 'C:\Program Files\GALEP32\Galep32.exe'` 7. Click Options, then click Application 8. Change "Lpt Port" from 378 to the correct value (in my case, `sudo lspci -vvv` said "I/O ports at e010" in the section for my parallel controller, so I changed 378 to E010) 9. Click "Test LPT Reliability" and click Start Everything seems to work fine with this method. I hope that helps. -- 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=54314 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #14 from Fabian Maurer <dark.shadow4(a)web.de> --- What would a correct solution roughly look like? Using the same API but somehow as NT driver? Not sure how that would work... -- 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=54314 --- Comment #15 from Matthew D'Asaro <medasaro(a)comcast.net> --- I thought I would give this a little poke. It would be amazing if we could have support for this back again. The proposed solution - giving Wine direct access to the address where the parallel port is - only works if the software program allows you to specify the IO port arbitrarily or if you have an old enough PC that the parallel port is actually at 0x278 / 0x378. The Willem programmer does not allow arbitrary addresses and I haven't found a way to remap the address of my PCI parallel port card to the standard 0x278 / 0x378. This wasn't a problem with old Wine versions as Wine remapped those addresses to /dev/partport0 which the parport kernel driver mapped to the actual hardware address. If someone can propose an architecture that we would like to use to implement this again, I am happy to work on coding it up. -Matthew -- 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.
http://bugs.winehq.org/show_bug.cgi?id=54314 --- Comment #16 from Alex Henrie <alexhenrie24@gmail.com> --- Hi Matthew! I'm not convinced that the original design of trapping writes to parallel port I/O space and emulating them was correct in the first place. Unlike serial-port-attached devices, parallel-port-attached devices (except for printers) are very sensitive to precise timings. That means that, for example, my Iomega Zip drive doesn't work if connected via a USB parallel port adapter, because USB introduces delays that throw off the timings. There were similar problems in Wine even when the device was connected to a parallel port on the motherboard: At <https://bugs.winehq.org/show_bug.cgi?id=3845#c8>, a user complained that when Wine was emulating writes to I/O space, the Willem flash programmer wrote incorrect data because the delays introduced by Wine itself were too much. In my opinion, Wine was going above and beyond its intended purpose when it emulated these reads and writes. The Willem software does not work on Windows with PCI parallel ports either because Windows likewise doesn't have any way to remap a PCI-attached port to the original IBM PC port range. Wine's general goal is parity with Windows, and "WINE Is Not an Emulator". But the nail in the coffin is that even when Wine was trying to be an emulator in this case, it didn't work right because of parallel port devices' inherent timing sensitivities. As I mentioned in comment #13, you can compile the ioperm program from https://gitlab.com/alexhenrie/ioperm and use it to run programs in Wine that require direct I/O access, and then they should be just as fast and reliable on Wine as they would be on Windows on the same hardware. And if you need to make the Willem software work with a PCI parallel port, you can use https://www.benryves.com/products/remappediodll which was created for that exact scenario and should work on Wine with ioperm. I'm inclined to close this bug as WONTFIX. Is there any other argument you can think of for why parallel port I/O emulation would be a good thing to bring back in Wine? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=54314 Alex Henrie <alexhenrie24@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #17 from Alex Henrie <alexhenrie24@gmail.com> --- Resolving as WONTFIX. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=54314 Gijs Vermeulen <gijsvrm@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #18 from Gijs Vermeulen <gijsvrm@gmail.com> --- Closing WONTFIX. -- 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 (3)
-
WineHQ Bugzilla -
WineHQ Bugzilla -
WineHQ Bugzilla