Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

BUG - FPC 2.5.1 snapshot (Announce)

posted by Rugxulo Homepage, Usono, 08.03.2011, 22:40

> > Firstly I thought that problem is in my disk
> > cache but it helped when I swithed from
> > cwsdpmi r5 into cwsdpmi r7.
> > (however best speed is with some nonswapping DPMI server
>
> Right :-)
Test r5 against r7 for anything significant, latest (w/ 4 MB pages) should be 2x faster.

Besides, CWSDPMI only creates a zero-byte swapping file at startup, doesn't actually expand/use it unless needed/accessed.

> > can't be generaly recomended at all - some
> > swapping is sometimes necessary)
>
> Wrong. You (or FP) have a BUG in memory management. Memory hogging can
> always fail. One must be always prepared to handle this case. Outsourcing a
> memory leak into a huge swapfile is a very bad idea (Windaube does this
> too) :-(
IIRC, you can limit the size of the swap file via CWSPARAM.

> > So - I vote for switching into cwsdpmi r7 in official distributions.
>
> Or kick it ;-)
FPC/DOS won't work without DPMI. Unless you want to resurrect the EMX (raw or VCPI) port or roll your own extender.

> > No, I do not consider any CWSDPMI release stable.
>
> I deprecate CWSDPMI (and actually DPMI at all). BTW, FPC has patched r5
> from 2008 :-( - just kick it :hungry:
I know it has r5 2008, that's good (SSE works now), but r7 is even better. Kick it? Like I said, FPC/DOS won't work without it.

> > I need a confmitation by somebody about this bug.
>
> Done!!! ( as again nobody else bothers, as usual in this "community"
> :-( )
I thought it was already fixed?!?

> Got:
>
> FPC251.ZIP 17'750'934
> B07F'165F'1394'3036'1086'CF7D'6DD1'B626
From here?

ftp://ftp.freepascal.org/pub/fpc/snapshot/v25/i386-go32v2/

> "fp.exe" 1'872'132 2011-03-07 16:41
>
> Result:
>
> Doesn't compile because LD.EXE is missing ... "switching to external
> linking" is nonsense, because LD.EXE is the external linker ... but
> where is the internal one ??? :confused:
I don't know, I'm not in the loop, but I just always assumed the internal linker was MS COFF (Win32) only. At least, I never heard that it fully worked with DOS (nor was ever barely tested there, if at all).

> Got further 20 MiB of bloat (containing LD.EXE) :
>
> BUG.EXE (sort of "Hello World" program) brewn (240 KiB :confused: )
-XXs -Os

> The BUG is still in :confused: even in "opti" 1 (but not if I comment out
> the "Confuse").
So don't write empty procedures. :-P Or perhaps {$ifdef} makes that harder to avoid?

> More problems:
>
> ### "install2.png" is bloated :-(
>
> INSTALL2.PNG 7'176
>
> INSTALL3.PNG 5'545 Saving factor 1.3 and __LOSSLESS__ !!!
Okay, good point, but surely you don't expect any sympathy there, do you? :-|

> ### UPX is still included, and binaries are still UPX'ed, with UPX
> 1.20 :confused:
>
> Solution: completely kick UPX from FPC :hungry:
It's up to the (non-existent) DOS maintainer to decide, not us DOS users. :-D

> ### CHM reader doesn't work, neither with FPC internal, nor with external
> files:
Who reads docs anyways? :-P

> > While the dos and win9x are both orphans maintainerwise,
> > the situation is different in that dos at least is its own platform.
If DOS/DPMI stuff fully worked like it did in Win9x days, even on XP / Vista / 7, we wouldn't be having such a shortage of users. Useless whining but true nonetheless. Nobody targets a non-existent (or broken) subsystem, and MS knows this. They want to avoid what happened to OS/2 ("too compatible" for its own good). Unfortunately, being totally INcompatible is bad for users. "DOS at least is its own platform", yes, but DPMI was invented by and for Windows. That will never change, no matter how hard anybody wants to say otherwise.

Post reply
 

Complete thread:

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