gspac/gspopt/gspcg now run, so the status table and examples cover the
full C path. gspcl itself still stops after gspac because the children
exit 139 at teardown; the manual pipeline is the working route. Note the
relative-path and consumed-intermediate requirements, the b15/sp
round-trip difference, and the non-zero exit statuses.
CMake 4.4's FindCurses leaves CURSES_HAVE_* unset on this system, so the
HAVE_CURSES_H fallback keeps viocalls compiling. Also fall back to
/usr/lib32/libncursesw.so.6 when the hard-coded Debian path is absent.
gspac/gspcg pass 0003:0000 (selector index 0, RPL 3) as a null far
pointer; lxConvert1616to32 only special-cased addr1616 == 0 and asserted
on ldt[0]. Segment index 0 is the null selector by definition, so return
NULL. This unblocks the TMS340 C front end (gspac), optimizer (gspopt)
and code generator (gspcg) under 2ine.
Fixes needed to run the 1990 TI 'TMS340 Family Code Generation Tools r5.01'
(16-bit OS/2 1.x NE, DOSCALLS-only) on 2ine:
* CMake: fall back to the system SDL2 headers when /usr/local/include/SDL2
is absent; the hard-coded path broke the build on stock distros.
* doscalls16: implement the entry points these tools import
- Dos16GetDateTime (33) with the OS/2 1.x *hours-first* 10-byte layout
(the year-first 8-byte layout crashes gspa in asctime/localtime)
- Dos16NewSize (68)
- Dos16GetHugeShift (135) / Dos16HugeIncr (136)
- Dos16CreateCSAlias (43), Dos16DevConfig (52), Dos16Move (67)
* lx_loader: walk NE fixup chains to the segment's 64K virtual size instead
of its file size, so fixups pointing into the BSS tail are applied. gspa
segfaulted in a lcall to its CRT exit handler because of this.
* doscalls: do not assert that the host PID fits in 16 bits (pid_max is
4194304 on current kernels); the 16-bit API truncates anyway.
Verified: gspa assembles a 2,412-line TMS34010 source with 'No Errors,
No Warnings', gsplnk links it with rts.lib, gsprom converts to Tek-hex.
The C compiler child (gspac via gspcl) still hits the lxConvert1616to32
selector assertion; see TMS34010.md.
Info-Zip unzip.exe uses this but doesn't actually _need_ anything but
stdout, so don't mess up the terminal if we don't have to.
We might actually _need_ to query terminal characteristics at some point
in a complete implementation of VioGetMode, but for now this is fine.
Not sure what Dos16MkDir2 is--probably a large extended attributes struct?--
but the real OS/2 toolkit defines DosMkDir and DosMkDir2 to be DosCreateDir,
so hopefully this is fine in general.
This will let the app set up some state about the OS/2 "system", like what
Unix paths are mapped to which OS/2 drive letters, system vars, etc.
This reads from /etc/2ine.cfg, and then tries a copy in the user's local
config dir to add/override settings.
This mostly doesn't do anything yet, but the framework is there for adding
stuff, and the drive letter mapping is done, even if nothing is using it.
This lets me remove my tcpip32 hack, and will let me export old symbols
as all caps for OS/2's use and something more sane for regular use
(like VioGetCurPos() in modern times is VIOGETCURPOS in viocalls.dll, etc).
This is read/write memory owned by the process, which can reallocate it,
which CMD.EXE does.
(FIXME comment by ryan, rest of the patch was from cracyc.)