Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Dillo - now a graphical web browser for DOS (Announce)

posted by obeythepenguin Homepage, United States, 27.11.2011, 18:58

Hi Rugxulo,

> EDIT: Almost forgot ... first things first, big thanks to you guys, Ben and
> Georg, for your excellent efforts.
:-)

> You'd have to already have Win95, which ain't free/libre. I'm not picking
> on it, just saying, it's harder to find these days. Honestly, choice of OS
> matters so little in this case, more important is network drivers.
I wasn't trying to push one OS over another -- I was just making an observation about Dillo's current performance. But you do raise a valid point. DOS is a good target for Dillo because of FreeDOS, which is both free/libre and much lighter than any Unix system could ever be.

(I also try to test Dillo regularly on ReactOS. Unfortunately it's not quite usable yet due to some bugs in their GDI implementation, though I have filed a bug report -- hopefully it will work better in their next release.)

Dillo-Win32 really was a stupid name choice on my part, considering I try to make my code as portable as possible -- the same code compiles and runs on Windows, DOS, OS X, and Unix (and I have binary packages available for most of them). How many other browsers can claim to support every major operating system of the last 20 years? ;-)

> As for RAM, you're using CWSDPMI, which can swap 'til the cows come home.
> (BTW, you're using here old r5 from 2000, not r7 from 2010, any reason? r7
> works fine for almost everything and is better / faster for big RAM
> machines. It's considered stable by CWS himself, so I suggest you upgrade,
> heh.)
I use r5 because that's what was marked "stable" on the DJGPP site. I'm not too experienced with DJGPP or DOS programming, so I've been fairly conservative with my package choices to err on the side of stability.

Having the ability to swap is nice, but I'd rather avoid the need to if at all possible.

> > Of course, it's not really a fair comparison since I've been doing the
> > Windows version longer, and thus it's much more aggressively optimized;
> I
> > just thought it was an interesting point of trivia.
>
> The higher footprint for DOS is due to the same reasoning: static linking.
> It's not that DJGPP doesn't have otherwise, but only barely.
The Windows version is also statically-linked, so I can distribute it as a standalone executable. It's also UPX-compressed -- uncompressed it's around 2.2 MB, I think -- while the DOS version is not currently compressed.

One other thing adding to the DOS version's footprint is OpenSSL. The Windows version links to CyaSSL, which is much lighter, but I don't know how well it supports DOS. (HTTPS support is present in the DOS build, though unfortunately I haven't yet gotten it to work.)

> For one thing, DJGPP still uses COFF, which clearly isn't a focus for GNU
> BinUtils optimizations. All their good work seems to go towards ELF.
>
> Secondly, DJGPP 2.03p2 "stable" is still recommended by some people because
> 2.04 was never finished. The former has only weak DXE1, the latter has
> better DXE3, which means dlsym, dlopen, etc. are supported (more or less,
> though latest GCCs 4.6.x seem to have broken this somehow). See Juan's
> /beta/ port of Lua 5.1.4.
>
> DJGPP's stub loads DPMI if none found and also puts the entire .EXE into
> memory. I'm not 100% sure on the details, but I guess? a DPMI host could
> demand page (and perhaps DPMIONE does, dunno), but most don't, e.g.
> CWSDPMI. So yeah, it loads the entire thing. I think DJGPP v1 did it
> better, but with v2 they went completely for DPMI (which is why a buggy
> NTVDM is so painful) to handle their own memory (instead of home-grown
> extender).
>
> Anyways, DJELF is on the mirrors, so if you really wanted, you could
> compile with that as it fully supports ELF shared objects. I'm not honestly
> sure if that will save memory here, as I don't know what the stub does
> (probably same ol' load all into RAM), but at least the local disk
> footprint would be smaller (though if Dillo is all you're using it won't
> save anything as it'll still need everything libc-related on disk). Or use
> UPX (sorry, marcov). :-P
Thanks for the information -- as I mentioned, most of the footprint is probably my own doing rather than DJGPP limitations, but it's good to know for future reference.

> Honestly, I don't consider 5 MB that big a deal in this day and age, esp.
> since GCC's CC1 is now like 8 or 10 MB (can't remember), also why it uses
> so much RAM these days compared to olden times (vaguely annoying but still
> works, more or less).
I'm just mildly obsessed with file size, that's all. My goal is to keep Dillo as small as possible, in keeping with the mainline project's objectives; when the Windows dillo.exe no longer fits on a floppy disk, I'll retire.

Post reply
 

Complete thread:

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