Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

FPC 2.6.4 released! (Announce)

posted by Rugxulo(R) Homepage, Usono, 20.03.2014, 04:24

> > 1). Extenders must play nice (or else have yet another neutral front end
> /
> > driver, maybe called from real mode??), I think Causeway would maybe
> > cooperate okay.
>
> Trouble is that must be weighted against modifying and validating the
> assembler (and linker) backend.

That sounds like tons more work (esp. internal linker) than just fixing a few things "as is".

> > 2). LFNs are a problem too, but at least Japheth's forked tools
> (JWlinkd,
> > JWlibd) support that, IIRC. (Otherwise we need another kludge. But see
> #5
> > below, maybe problem is already solved??)
>
> No idea, haven't revisited. But yes it is increasingly a problem.

I know this isn't top priority. But, as is, I'd suggest:

1). drop DOS4GW in lieu of CWSTUB (aka Causeway, which mostly cooperates okay with GO32v2 extender, I think?)
2). use Japheth's forked tools: JWlib, JWlink (LFN support, though J- tools use his own built-in HX-derived extender, I think??)
* or maybe?? use OW 2.0-pre DOS tools snapshot (which claim to have fixed the lack of LFN support)
3). modify FPC to generate response files automatically instead of super long cmdlines

> > 4). I'm quite skeptical about honestly getting Wlink / JWlink etc. to
> build
> > with DJGPP, even though it probably builds with GCC on Linux. At least
> > JWasm used to claim to build with DJGPP, but the others I dunno. I doubt
> > Japheth (or OW devs) care enough to waste time on this.
>
> I also wouldn't waste too much time switching assemblers. That can be
> better invested in an internal asm that is generally more stable,
> crossplatform, has no LFN issues etc.

No, I know that, I meant that JWasm was the only tool that 100% claimed to support being bootstrapped itself with DJGPP (see JWasm211as.zip's GccDos.mak). I've not noticed nor heard any attempt for other tools, though. I don't recommend replacing the assembler (esp. since syntax is different), though JWasm indeed is "stable, fully cross-platform, has no LFN issues etc."

> > But I'd have
> > to try again. In other words, unless somebody explicitly tries [FPC+HX] and
> > succeeds, I just assume that's not going to work at all. Again, I doubt
> > Japheth cares enough to waste time fixing this.
>
> So I assume that means that HX is not long term viable anyway, ok, option
> dropped.

It's not viable unless somebody (either FPC or HX) is willing to pick up any slack. Sure, HX works great, but it can't support everything. So if FPC is gung ho about using every API in the book (without testing HX first), that's going to be a problem. It's probably not reasonable to expect Japheth to do everything himself (or anything at all, dunno his plans, I expect nothing).

> > The current FPC snapshot says (ppcross386 -iD) 2014/02/05 but -iSO and
> -iTO
> > both say "win32". A weak try (atop Win7 64-bit) to compile fpctris
> > (-Fuunits/go32v2/rtl) says, "PPU is compiled for another target".
>
> FPC compilers are per architecture. So any 32-bit x86 compiler can generate
> go32v2 code. The target OS can be changed with -T.
>
> But for 16-bit you need a 16-bit arch compiler

Dunno, maybe I got the wrong snapshot.

> > > > The IDE shelling out / compile + run bug seems fixed.
> >
> > Haven't tried the built-in debugger, that's what I always associated
> Pierre
> > with, mainly (for good or bad).
>
> True. It seems that the debugger was left out, and he was planning to
> upload an add-on package to fix that.

Laaca will have your head. :-P

 

Complete thread:

Back to the forum
Board view  Mix view
15108 Postings in 1358 Threads, 246 registered users, 10 users online (0 registered, 10 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum