This commit fixes most -Wzero-as-null-pointer-constant warnings, except in
some places which appear to be vendored 3rd party libraries, e.g. in sdl_ttf.c,
libchdr, physfs and gmock and in 3rd party components therein. Since it might
make more sense to update this 3rd party code to some later versions instead of
fixing the warnings manually, I decided not to enable the C++ compiler flag in
configure.ac at this point.
In two functions with the return type of std::string executed `return 0;`
statements, causing std::string to be constructed from a null pointer. To avoid
undefined behavior these were changed to `return {};`.
Signed-off-by: Jaak Ristioja <jaak@ristioja.ee>
- Made hardopl.cpp use libpassthroughio, so it can now work for all platforms supported by libpassthroughio.
- Moved prototypes of interface from sblaster.cpp to new header hardopl.h.
- Made hardopl.cpp compile cleanly with Visual Studio 2019.
- Kept the functionality disabled, because I do not have access to the necessary hardware. The pass-through functionality itself has been successfully tested on Windows 10 and Linux 5.15. It can be enabled with a 1 character change to hardopl.h.
+ If it is to be officially enabled, we need a slightly more sophisticated handling of privileges on UNIX. No problem, but I will not touch that code unless OPL pass-through is actually desired. For now, either run as root (through sudo) or disable the call to dropPrivileges() in parport.cpp when running setuid root if OPL pass-through is desired.
- Added support for FreeBSD, OpenBSD, NetBSD and DragonFly BSD.
+ It is quite unlikely that the original Win32 implementation worked with the HX DOS extender on DOS as it required loading inpout32.dll which depends on a Windows kernel driver. This implementation is expected to work, because it supports direct I/O too. I am unable to verify that though.
- Made direct I/O available on all platforms, because it is desirable everywhere, including on Windows. On the BSDs it is the only interface available.
+ Least amount of latency. I/O through inpout32.dll/inpoutx64.dll or Linux's ppdev adds a significant amount of overhead. Measurements with inpout32.dll show that practical, real-world overhead can be as large as 400%, i.e. I/O taking 4 times longer than direct I/O.
+ For some devices, direct (read) access to the parallel port control register is needed which ppdev does not allow.
+ Not all parallel port PCI(e) cards are supported by ppdev. Perhaps most are not. Direct I/O works everywhere, because no host OS support is needed.
+ Made possible on 64-bit Windows by giveio64 and on 32-bit Windows by AllowIO (part of the PortTalk package). On Linux, FreeBSD, OpenBSD, NetBSD and DragonFly BSD on x86(_64), direct I/O will be enabled after opening a special device (/dev/io on FreeBSD & DragonFly BSD) or making a special system call (*iopl()).
- Visual Studio allows inline assembly only for x86 builds. However, the intrinsics __in{byte, word, dword}() and __out{byte, word, dword}() work for both x86 and AMD64 builds. Visual Studio versions older than 2015 have _inp{w, d}() and _outp{w, d}(). Those intrinsics also work on both x86 and AMD64 platforms. Visual Studio 2022 still has them too, but only for C (not for C++).
- Put inpout32.dll/inpoutx64.dll loading code in the new passthroughio library so that the functionality can be shared between parallel port and other pass-through code. For example, the original OPL pass-through functionality by Ralf Grillenberger ("h-a-l-9000", author of DOSBox Megabuild 6 where virtually all pass-through code in DOSBox-X originated from) could be enabled, although it looks there has not been any demand for that in DOSBox-X (the Windows-only implementation in DOSBox-X has been disabled a long time ago). Regardless, it is cleaner to separate the low-level I/O code from the parallel port pass-through code.
- Since the PortTalk interface (src/libs/porttalk) is no longer being used I removed it.
+ AllowIO can still be used on systems where the PortTalk device driver could be used.
- Direct I/O will be used if possible. Only on Linux one can actively avoid that by specifying realport instead of realbase in the configuration file.
+ On Linux and the BSDs the code will use direct I/O only if the effective user ID is 0 (root), because only then direct I/O is possible.
+ On Windows the code installs an exception handler and it will load inpout32.dll/inpoutx64.dll only if direct I/O causes an exception. Be aware that if reallpt is specified in the configuration file, when debugging with Visual Studio, that exception will be caught by the Visual Studio debugger instead (unless you start giveio64 beforehand).
- Solved issues with writing to the control register (changing I/O direction with ppdev was not implemented).
- Applied a better solution to a former issue in src/hardware/parport/parport.cpp that caused PARALLEL_Read() and PARALLEL_Write() to silently fail. See https://github.com/joncampbell123/dosbox-x/issues/2214.
- Corrected write to potentially invalid ECR address in CDirectLPT::~CDirectLPT() (ecpbase was ignored when restoring the value of the extended control register).
- Corrected code that enabled parallel port IRQ (could have caused trouble for some people as the code does not and cannot install an IRQ handler on most host OSes).
- Re-enabled code that sets the parallel port to bidirectional mode when using direct I/O and added code that does the same for Linux's ppdev.
+ Bidirectional mode is the most compatible mode.
+ Setting *a* mode is better than just relying on whatever is set in the BIOS or UEFI or whatever the state of a PCI(e) parallel port card is in after booting.
- Added code to reset the EPP Time-out state.
- Made log messages explicit about whether pass-through has been enabled, identifying the parallel port, thereby clarifying the situation to the user.
- passthroughio.cpp compiles cleanly with MinGW (GCC 9), MinGW-w64 (GCC 12 and Clang 15), Cygwin 32-bit (GCC 11), Cygwin 64-bit (GCC 11), Visual Studio 2015 (x86 & amd64), Visual Studio 2019 (x86 & amd64), Visual Studio 2022 (x86 & amd64), GCC 12 on Linux/x86_64 and GCC 8 on Linux/armv7.
+ The resulting code has been successfully tested on Windows 10 Pro, Linux/x86_64 and Linux/armv7.
- All changes compile cleanly as part of DOSBox-X v2022.12.26 with MinGW (build-mingw, build-mingw-lowend (after manual intervention because of broken build scripts), build-mingw-lowend-sdl2 (after adding "-lz -liconv" to LIBS in src/Makefile)), Visual Studio 2019 (amd64), GCC 12 on Linux/x86_64 (build-debug-sdl2) and GCC 8 on Linux/armv7 (build-sdl2).
- The resulting DOSBox-X executables (MinGW (build-mingw, build-mingw-lowend) & ones built with native GCC) have been successfully tested with actual (non-printing) hardware attached to a parallel port on:
+ Linux (Raspberry Pi OS) on Raspberry Pi 2B (with pi-parport, using ppdev)
+ Windows 2000 and Windows XP on laptops using inpout32.dll and AllowIO (tested on Windows 2000 only) (thanks to Mystic_Merlin)
+ Linux (Debian) on HP Thin Client T510 using ppdev (thanks to NorQue).
The executable produced with build-mingw-lowend-sdl2 failed on a DirectSound issue during start up (on Windows XP and Windows 10).
