LFN: too many dirs open about comcom64 HOT 3 CLOSED

Should now be fixed, although it
will take some time for new dj64dev
being built, and then a new comcom64
being built with it.
Fixing this on comcom32 is not possible
unless @jwt27 back-merges all the patches. :)

from comcom64.

Fixing this on comcom32 is not possible
unless @jwt27 back-merges all the patches. :)

Well, you know how I feel about diverging from upstream. And these patches are all specific to one very niche use case, which only you seem to be doing :)

Maybe it makes sense for a shell to have its own libc. You can still use the djgpp toolchain, just link with -nostdlib and provide your own libc/crt0 fork. More or less what you already did with djdev64.

Must say I'm impressed by what you accomplished with that, in such a short time. I don't think I mentioned that yet. Especially moving to ELF is a great choice, I think djgpp should have adopted that a long time ago.

from comcom64.

Well, you know how I feel about diverging from upstream.

But you can sync with upstream, or?

And these patches are all specific to one very niche use case, which only you seem to be doing :)

You mean findclose() patches?
I think they are rather generic.
Just to be clear: have you looked
exactly into the patches referenced
in this ticket, or some others?
I reference them per-ticket exactly
to simplify back-merging, in case
someone wants to.

You can still use the djgpp toolchain, just link with -nostdlib and provide your own libc/crt0 fork.

You mean for comcom32?
No, this is not an option.
comcom32 is deprecated.
I only do the bits of work for it
because it is buildable from the
same source tree with comcom64.
I am not going to invest any real
efforts into it, over a few ifdefs.
If it keeps leaking ff handles in
some scenarios - fine with me. :)
I have comcom64 that doesn't.

Must say I'm impressed by what you accomplished with that, in such a short time.

It was a few years actually, but thanks! :)
Fortunately this was a second porting project
(fdpp was the first one), so in this case
I was just porting the fdpp thunking
infrastructure to djgpp most of the time,
rather than writing things from scratches.

Especially moving to ELF is a great choice, I think djgpp should have adopted that a long time ago.

It did an attempt. There is an elf32 frame-work
by Daniel Borca:
https://www.geocities.ws/dborca/djgpp/elf/djelf.html
I haven't tried that but others did -
it works. Why they didn't take it?
Well, who knows... But as it stands,
I have a chance to push dj64dev to
distros (like debian), write a 64bit extender
for DOS, and phase out djgpp entirely. :)
Writing a 64bit extender for DOS is a
culprit though.

from comcom64.