elks
elks copied to clipboard
ghaerr
Add support PM MC NCURSES?
Are there any plans to add a package manager? Porting ncurses and midnight commander?
P.S. Has anything been decided about the support of EMS and UMB?
P.S.S. Its no BUG. I don't know how to remove the BUG status
Hello @AirmanKaluga,
Are there any plans to add a package manager?
No, as most all ELKS applications are still compiled within the source tree at this time; Would this be for easily importing binary programs into ELKS, or source?
Porting ncurses and midnight commander?
Ncurses has been ported, and lives alongside the nano text editor under elkscmd/nano/ncurses-5.2/. It is functional and used with the nano editor, but has proven to be unwieldy under ELKS, due both to its use of the GNU configure mechanism, as well as its relatively large size. However, the compiled library can be found at elkscmd/nano/ncurses-5.2/lib/libnurses.a by adding 'nano' back into elkscmd/Makefile::SUBDIRS=.
Midnight commander has not been ported. Are you aware of a version which would be well suited to ELKS running in 16-bit real mode?
P.S. Has anything been decided about the support of EMS and UMB?
EMS support through use of the MSDOS-style EMS API will not be supported. However, both memory available between 640K and 1M is supported now for use in the ramdisk driver. This would include non-bank-switched EMS, and UMB memory. That memory has not been added to the application memory manager, as it is of less use given the way ELKS currently places applications in memory.
What are your needs for this EMS or UMB at this time?
Thank you!
Switching pages is the most interesting. They can be used to host these programs. Make an address translator with copying to the main memory or place executable programs in this memory and, as tasks switch, switch the EMS memory page. Something like this. There is no 16-bit commander, but I think you can sport the code by discarding everything superfluous
Switching pages is the most interesting. They can be used to host these programs. Make an address translator with copying to the main memory or place executable programs in this memory and, as tasks switch, switch the EMS memory page.
Yes - that would be very similar to the MSDOS EMS implementation. The reason this hasn't been done is that there are no large programs which currently use EMS that are trying to be ported to ELKS (as well as the complication of having a large variety of hardware EMS cards which might need to be individually supported). If/when they are ported, we would then have to implement the original EMS API, which is a lot of work, given that ELKS doesn't implement any DOS APIs. With ELKS' current limitation on both kernel and application data segment size at 64K, the programs run out of memory earlier than when main memory is exhausted.
There is no 16-bit commander, but I think you can sport the code by discarding everything superfluous
It would be nice to see a port, someone needs to look at the source to see whether its design is such that the data segment could be trimmed to 64K, as that's a hard limitation of our compiler without huge model support. I found when porting nano, the supposedly smallest great visual editor, that it's just way too large to run well on ELKS. We got it running, but it can only edit files of approximately 2-4K in length, due to the ultimate data segment size limitation.
Thank you!
OK so there are a number of lightweight ncurses managers:
https://github.com/FedeDP/ncursesFM
https://github.com/mananapr/cfiles
First one might work with disabling some features
Hello @ghaerr ,
I also have interests using ncurses so I built nano and libncurses.a.
Where should I place this file and how can I load this in ELKS?
I just placed nano and libncurses.a in the same directory of PC-98 hard disk but it seems not working.
Also do I need to shorten libncurses.a file name and rebuild if I cannot use LFN?
Thank you!
libncurses.a is a static archive library file, that means it has to be passed on the link line (as is done in the nano Makefile) in order to statically link with your program. There are no shared libraries in ELKS.
nano should run as-is (no need for seperate .a file). It does require kernel support for medium-model binaries to run, so make sure that CONFIG_EXEC_MMODEL=y is set in .config. What happens when you try to run nano?
Note that nano is so large that it will only run with a small input file. This is because of the 64k data segment size limitation on 8086. The libncurses.a is also huge, so don't expect too much when using it - I think it also may be a data segment hog.
Also do I need to shorten libncurses.a file name and rebuild if I cannot use LFN?
Currently, our FAT implementation allows opening LFNs, but not creating them. So, if the disk image is being built using mtools, then the long libncurses.a will be created properly. In general, none of this should matter though on ELKS itself as libncurses.a is not needed at runtime - you must link your executable with it during compile/link time.
Thank you @ghaerr ,
I see. Nano says as follows. (Also hang-up with my simple test program)
Maybe different problem. I will look again when I have time.
so don't expect too much when using it
I am thinking porting some rogue clone game just for fun :)
Thank you!
Nano says as follows.
Hmmm... "Syntax error:" means that shell is treating it like a shell script since kernel rejected the file as an executable. Try perhaps also turning in CONFIG_EXEC_COMPRESS=y, it should not be required but could be an issue. It is also possible, but unlikely, that FAT filesystem could be an issue, as I've never tried running nano from FAT.
I will try looking into this later today to see why, I haven't run nano in a while. Also, if you run sash (shell) first, it should give exact errno as to why kernel is rejecting execution (/bin/sh will try as shell script, while sash does not).
@tyama501,
Very strange - nano works on my system both on FAT with and without CONFIG_EXEC_COMPRESS. I am wondering if this is a build issue because of the highly complicated ./configure script (that isn't being run on ELKS build).
Try running this version which I just built and works: nano.zip
Thank you @ghaerr ,
I could run your binary. (although it says sys_blk fail, nano is out of memory when tried to save)
I noticed that your binary 140KB is a lot smaller than my binary 270KB. So it seems I couldn't build right.