FDOS / share

Installs file-sharing and locking capabilities for FreeDOS kernel. (Not compatible with other DOS kernels.)
11 stars 5 forks source link

AMIS branch - AMIS multiplexer, uninstaller (patches old kernel flag), status display, install tweaks #11

Closed ecm-pushbx closed 3 years ago

ecm-pushbx commented 3 years ago

Note that building this requires to include lmacros3.mac, lmacros2.mac, and lmacros1.mac - these files are available at https://hg.pushbx.org/ecm/lmacros/ and must be either in the same directory as gcc_help.asm or in ../lmacros/

Also note that this relies on ia16 gcc for now, Turbo C build is severely broken.

andrewbird commented 3 years ago

Note that building this requires to include lmacros3.mac, lmacros2.mac, and lmacros1.mac - these files are available at https://hg.pushbx.org/ecm/lmacros/ and must be either in the same directory as gcc_help.asm or in ../lmacros/

I'm not sure relying on external files to be present is a good thing, can't they be included here? Currently share is built alongside the gcc version in the kernel repository Github Action which will surely break if they are not present.

Also note that this relies on ia16 gcc for now, Turbo C build is severely broken.

In what way, just missing features, or something else?

ecm-pushbx commented 3 years ago

I'm not sure relying on external files to be present is a good thing, can't they be included here? Currently share is built alongside the gcc version in the kernel repository Github Action which will surely break if they are not present.

Yes, you can add them to the SHARE directory alongside AMIS.MAC if you prefer. Make sure to add a link to the source in the commit message and/or somewhere else.

Also note that this relies on ia16 gcc for now, Turbo C build is severely broken.

In what way, just missing features, or something else?

It won't build. To make it build you either need to add lots of #ifdef style conditions, or port the additional assembly source to make it work with Turbo C. The asm_* functions called from C currently assume a gcc ia16 cdecl calling convention (parameters on the stack in "reverse", caller cleans stack space, ax bx cx dx are call-clobbered, ax is the return value); I don't know whether this is the same for Turbo C. And this would likely increase the (resident) size by at least 700 bytes (just from the transient assembly source, additional transient C source not counted), as it seems the Turbo C build left the entire executable resident.

PerditionC commented 3 years ago

I plan on updating the build on Monday. I am building on windows 10 64bit and Linux now, so realized there are issues with the current build system. I will likely require gmake regardless of platform and compiler instead of gmake on Linux and combo batch/compiler make elsewhere. I need build utilities to build for native os while resulting programs still build as DOS programs. I previously used 32bit Windows so could natively run DOS binaries during build and only used make build on Linux. This comment is mostly directed at kernel, but share is a submodule of it. Although GCC is the preferred compiler for share now, I do intend to have it build with Borland and Open Watcom, though feature parity is not guaranteed. To summarize, I will ensure it continues to build on GitHub (all needed files are in repository) and work on better support for other build environments (compilers and OSes). With a new (pre?)release as part of kernel to be out Sunday or Monday.