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@winehq.org Reporter: jacek.zmudzki@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.
https://bugs.winehq.org/show_bug.cgi?id=54314
Zeb Figura z.figura12@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
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #1 from Austin English austinenglish@gmail.com --- Please run a regression test: https://wiki.winehq.org/Regression_Testing
https://bugs.winehq.org/show_bug.cgi?id=54314
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware CC| |alexhenrie24@gmail.com
--- Comment #2 from Alex Henrie alexhenrie24@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?
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #3 from Jacek Zmudzki jacek.zmudzki@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@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@winehq.org
configure | 35 ----- configure.ac | 12 -- dlls/krnl386.exe16/ioports.c | 318 ------------------------------------------- include/config.h.in | 3 - 4 files changed, 368 deletions(-)
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #4 from Jacek Zmudzki jacek.zmudzki@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
https://bugs.winehq.org/show_bug.cgi?id=54314
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |d637640f9af4ccfb6639361fc54 | |8d4bbeaafeb6f
--- Comment #5 from Alex Henrie alexhenrie24@gmail.com --- Great job on the regression test!
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #6 from Alexandre Julliard julliard@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.
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #7 from Alex Henrie alexhenrie24@gmail.com --- As a workaround, you can try running the program with direct I/O access, such as with https://gitlab.com/alexhenrie/ioperm
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #8 from Jacek Zmudzki jacek.zmudzki@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...
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #9 from Alexandre Julliard julliard@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).
https://bugs.winehq.org/show_bug.cgi?id=54314
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |medasaro@comcast.net
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- *** Bug 54520 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #11 from Matthew D'Asaro medasaro@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.
https://bugs.winehq.org/show_bug.cgi?id=54314
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- We can support it, but it needs to be rewritten.
https://bugs.winehq.org/show_bug.cgi?id=54314
Alex Henrie alexhenrie24@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@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.
https://bugs.winehq.org/show_bug.cgi?id=54314
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #14 from Fabian Maurer dark.shadow4@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...
https://bugs.winehq.org/show_bug.cgi?id=54314
--- Comment #15 from Matthew D'Asaro medasaro@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
-
WineHQ Bugzilla