Rebuilding 2.04 from source

[Louis Santillan]

I've noticed most people have moved on from using DOS to build the official ports.  Some use various Windows versions, others use Linux.  To that end, I don't want to lose the ability to "self-host" on DOS.  When others have used Windows, which win32 tools have you used?

I was thinking of attempting to use HX-DOS Extender and either CygWin or MinGW to rebuild 2.04.  Anybody have suggestions, guides, etc.?

-L

[Eli Zaretskii]

> Date: Sun, 23 Jun 2013 20:38:12 -0700
> From: Louis Santillan <lpsa...@gmail.com>

You don't need any cross-building environment, as long as you use
Windows XP or older, and don't use 64-bit versions of Windows. DOS
programs simply run as is.

[rug...@gmail.com]

Hi,

On Sunday, June 23, 2013 10:38:12 PM UTC-5, Louis Santillan wrote:
>
> I've noticed most people have moved on from using DOS to build
> the official ports.  Some use various Windows versions, others
> use Linux.  To that end, I don't want to lose the ability to
> "self-host" on DOS.  When others have used Windows, which win32
> tools have you used?

The very few times I naively tried "./configure" under pure DOS
with DJGPP Bash and LFNs enabled, it didn't work. I don't know if
regenerating the script with an older DJGPP port of ACNF213B.ZIP
would help or not, but I heavily doubt it (and wasn't interested
enough to learn all the arcane boring details).

> I was thinking of attempting to use HX-DOS Extender and either
> CygWin or MinGW to rebuild 2.04.  Anybody have suggestions, guides,
> etc.?

I haven't really tried, but I'm 99% sure you can't use Cygwin
(especially not 1.7, but probably not even 1.5 Win9x, non-Unicode
version) without lots of improvements to HX.

The best you can hope for is (maybe) some rare MinGW standalone tool,
but even then you have to use MSVCRT (e.g. one from older ReactOS
0.3.14 seems to semi-work) and set HDPMI=32 and DPMILDR=136 or 128
or whatever. IIRC, even MSYS uses a Cygwin-compiled Bash.

You can (and Juan frequently does) rebuild the libc (e.g. from CVS)
in pure DOS, but there is some rare NUL bug in FreeDOS that may require
one or two minor workarounds. (I don't know why exactly reading from
the NUL device is ever considered wise, but whatever.) Usually I don't
rebuild the libc because it feels too brittle to my tastes, but it's
(apparently) not very hard. IIRC one of the Lua 5.2 threads was when
Juan told me various details about it, so you could read that (or
just try it and report back on any difficulty).

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:713e6460-511d-4b27...@googlegroups.com...

> > On Sunday, June 23, 2013 10:38:12 PM UTC-5, Louis Santillan
> wrote:

> > I've noticed most people have moved on from using DOS to build
> > the official ports. Some use various Windows versions, others
> > use Linux. To that end, I don't want to lose the ability to
> > "self-host" on DOS. When others have used Windows, which win32
> > tools have you used?
>
> The very few times I naively tried "./configure" under pure DOS
> with DJGPP Bash and LFNs enabled, it didn't work. I don't know if
> regenerating the script with an older DJGPP port of ACNF213B.ZIP
> would help or not, but I heavily doubt it (and wasn't interested
> enough to learn all the arcane boring details).

My results with configure scripts have been it either works or it
doesn't. When it doesn't, generally the code is using something
the DJGPP doesn't support. When it does, the app compiles for
DJGPP. I.e., if the configure script doesn't work, it's a strong
indication it won't compile without some work.

> > I was thinking of attempting to use HX-DOS Extender and either
> > CygWin or MinGW to rebuild 2.04. Anybody have suggestions,
> > guides, etc.?
>

> [...]

> The best you can hope for is (maybe) some rare MinGW standalone
> tool, but even then you have to use MSVCRT (e.g. one from older
> ReactOS 0.3.14 seems to semi-work) and set HDPMI=32 and
> DPMILDR=136 or 128 or whatever. IIRC, even MSYS uses a
> Cygwin-compiled Bash.

MinGW in DOS with HX... Interesting. How many functions are in
MSVCRT? I.e., would it be easy to port MinGW to DOS?

My first question to Louis is how could MinGW rebuild DJGPP
without POSIX support? CygWin has POSIX support.

My second question is to Louis is why you're rebuilding version
2.04? 2.04 doesn't work as well with DOS as 2.03. There are some
definate bugs with it, at least with MS-DOS v7.10. IIRC, 2.04 is
designed to work better in a Windows XP console ("dosbox") window,
not real-mode DOS.

<OT>
Rugxulo, I know I need to get an email account and get on "DOS
ain't dead forums"... But, until then, could you do me another
favor and let Japheth know I posted a patch for HIMEMX to
comp.os.msdos.programmer? It supports multiple 001 E820h memory
blocks above 1MB. If you recall, you posted a message or two there
for me previously discussing the issue.

If you do, thanks and sorry for the trouble...
<eOT>


Rod Pemberton

[rug...@gmail.com]

Hi,

On Monday, June 24, 2013 3:51:14 PM UTC-5, Rod Pemberton wrote:
>
> My results with configure scripts have been it either works or it
> doesn't. When it doesn't, generally the code is using something
> the DJGPP doesn't support. When it does, the app compiles for
> DJGPP. I.e., if the configure script doesn't work, it's a strong
> indication it won't compile without some work.

I'd honestly rather roll my own tools than use those. Well, the fact
that it doesn't barely work on DJGPP anyways makes that almost
unavoidable.

> MinGW in DOS with HX... Interesting. How many functions are in
> MSVCRT? I.e., would it be easy to port MinGW to DOS?

I don't think the full MinGW environment works, but I've not tried.
Some standalone tools (or those compiled by) do work. E.g. Oxford
Oberon or TinyC (often needing HDPMI=32 or DPMILDR=136). BTW,
TinyC had a big update recently.

MSVCRT is a "known .DLL", originally (I think?) from MSVC 6. MinGW
and TinyC use it, but OpenWatcom (thankfully) doesn't. It's very
proprietary, so I'm not sure (at least in Express Editions) you can
share it with anyone. (There are other .DLLs from other MS compilers.)
It only supports C89 as (IIRC) MS still do not intend to support
anything newer except via C++.

Like I said, newer ReactOS .DLL doesn't work, but older 0.3.14
MSVCRT.DLL seems to work with HX, at least for the very few apps
I tried.

I don't know what "port MinGW to DOS" means, but I'm very very
skeptical.

> My first question to Louis is how could MinGW rebuild DJGPP
> without POSIX support? CygWin has POSIX support.

Presumably MinGW added a few POSIX stubs as GCC wouldn't run without
such.

> My second question is to Louis is why you're rebuilding version
> 2.04? 2.04 doesn't work as well with DOS as 2.03. There are some
> definate bugs with it, at least with MS-DOS v7.10. IIRC, 2.04 is
> designed to work better in a Windows XP console ("dosbox") window,
> not real-mode DOS.

2.04 (circa 2003) "mostly" works fine for everything I tested. Sure,
there are some rare bugs, but they were fixed in CVS (not that I
really tried that). The only problem with 2.04 is that it wasn't
as heavily tested in all environments as 2.03p2. Plus, there's been
no release manager nor major interest since it was always "good
enough" for the main developers. At least, that's what little I
recall understanding about it. I don't have anything against
2.03p2, but I'm not sure that's totally perfect either, for
various minor reasons.

> Rugxulo, I know I need to get an email account and get on "DOS
> ain't dead forums"...

No pressure! :-) I know you hate email, but perhaps GNU PG would
help??

> But, until then, could you do me another
> favor and let Japheth know I posted a patch for HIMEMX to
> comp.os.msdos.programmer? It supports multiple 001 E820h memory
> blocks above 1MB. If you recall, you posted a message or two there
> for me previously discussing the issue.

Sure, but keep in mind that Japheth long ago disclaimed any hold
over HimemX, so he's not really a maintainer (anymore, if ever).
IIRC, he even refused the simple "jmp $+2" 386 patch. :-(

Though worst case, I'll just try to mirror your patch to iBiblio.

> If you do, thanks and sorry for the trouble...

No trouble, but my usefulness is limited. But I've gone ahead and
posted there, so we'll see what he says.

[Louis Santillan]

So rugxulo & Rod are following.  I am looking to build DJGPP completely from scratch on a DOS box.  If you reference typical GCC porting guides [1][2][3][4], you start by building binutils, then GCC's deps (if using 3.x or later), then GCC, all using the typical ./configure && make && make install.

-L

[1] http://wiki.osdev.org/DJGPP

[2] http://wiki.osdev.org/C%2B%2B_Bare_Bones

[3] http://wikiosdev.org/GCC_Cross-Compiler

[4] http://virtuallyfun.superglobalmegacorp.com/?p=333

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:a5de500e-67da-4fc7...@googlegroups.com...

<OT>

> BTW, TinyC had a big update recently.

Ah! I'd stopped checking for updates of it... Thanks.

> I don't know what "port MinGW to DOS" means,
> but I'm very very skeptical.

Basically, I was asking how difficult it would be to create a DOS
only version of MinGW. If MSVCRT has many functions and MinGW
uses many of them, it'll take much coding to remove or replace
them. If the MSVCRT functions MinGW uses are complicated, not
simple, it'll take even more work. Some C libraries only need
about 20 functions to bootstrap, while others need many.

If yet another DOS C compiler is needed, it might be better to get
the DOS versions of LCC, versions 3.5 and 3.6, working again.
Then, migrate useable updates from 4.1 and 4.2 back.

Or, it might be better to de-Linux-ify TCC, e.g., remove the dlopen
and dlsym related code, do test compiles with DJGPP, and figure out
how to bootstrap later, perhaps with the old TurboC.

> [...]but OpenWatcom (thankfully) doesn't.

I was using OW v1.3, but I've basically stopped using it. By
comparison, code for DJGPP just compiles and works. It's
definately not better though. OW doesn't support the piping like
DJGPP. OW does catch certain errors better, e.g., signed vs
unsigned character mismatches. OW also has some wierd issues with
buffering of stdin and stdout, i.e., don't change the buffering.
OW generates faster code than DJGPP. OW also generates far
superior x86 byte-sized instructions for characters, e.g., using
AL, AH, BL, etc. Although, it is possible to get DJGPP to do so
using carefully crafted C code. OW is also very good for
identifying code that DJGPP or GCC or Linux supports, but other DOS
compilers don't, e.g., POSIX, DPMI, LFN, etc. That version of OW
doesn't support LFN and DPMI as well either, i.e., you have to
setup the entire function call, whereas DJGPP has setup most of
these as a function for you already. I'm not sure what has changed
or been fixed since v1.3.

> I know you hate email, but perhaps GNU PG would help??

Doesn't that need an email account to work? I guess you could use
it with NNTP. But, that doesn't eliminate the need for an email
account in order to setup other accounts for forums, etc. I.e., I
don't need privacy, I need to be able to setup accounts which don't
also require an email account to setup. What's the point of that?
You can't confirm the identity of the email account holder
either... It's like a merchant asking for a credit card before
accepting a cash payment (illegal in the US, BTW). I could use a
trash mail service, but I run the risk of having private
information, e.g., login or account confirmation info, sent to a
junk account or a temporary account which might exist for only a
short time period. What I need is a no email, browser based,
account setup form for forums etc. Unfortunately, US law requires
a birthdate under certain account setup situations. So, those
requirements are generally applied to the setup of most accounts,
email or other in the US, whether they're actually required or not
by law. The just web seems to be against me. So, I may need to
get a non-US email account to protect my personal information and
let me create accounts elsewhere.

> Sure, but keep in mind that Japheth long ago disclaimed any hold
> over HimemX, so he's not really a maintainer (anymore, if ever).

Oh, I didn't realize he disclaimed maintainership.

> IIRC, he even refused the simple "jmp $+2" 386 patch. :-(

I included the corrected version of that in my patch.

> Though worst case, I'll just try to mirror your patch to iBiblio.
>

Thanks.

If Japheth ignores it, rejects it, or doesn't have time for it,
then I could package up one with the exe. Then, you could do me
yet another favor and mirror it on your website (lol). However, I
was hoping the code could be reviewed by someone skilled in x86 and
experienced with Himemx too, like Japheth, Devore, or some of the
guys on DOSX, before being hosted on iBiblio, on Japheth's site, or
on your site. My main concern is I can't test some of the really
old machines HIMEMX works on. I also can't currently test the
machine it was intended for. I may get it working by this fall.
So, I just don't know if I introduced any unintended errors.


Rod Pemberton

[Eli Zaretskii]

> From: "Rod Pemberton" <do_no...@notemailnotq.cpm>
> Date: Wed, 26 Jun 2013 04:05:30 -0400

>
> Basically, I was asking how difficult it would be to create a DOS
> only version of MinGW. If MSVCRT has many functions and MinGW
> uses many of them, it'll take much coding to remove or replace
> them. If the MSVCRT functions MinGW uses are complicated, not
> simple, it'll take even more work. Some C libraries only need
> about 20 functions to bootstrap, while others need many.

MinGW basically provides:

. system header files required to compile programs

. import libraries required to link programs such that they will use
Windows DLLs (including, but not limited to, msvcrt.dll) at run
time

. startup code to be linked into each program, and

. a relatively small library of additional functions that Windows
does not provide, such as gettimeofday

Given the above, and the fact that the Windows DLLs provide hundreds
if not thousands of useful functions (and msvcrt provides all the
standard C functions and then some), I think it should be clear that
"DOS only version of MinGW" does not make any sense, because MinGW's
goal is to provide the _minimal_ infrastructure needed to build
programs that will use Windows DLLs at run time.

[rug...@gmail.com]

Hi,

On Tuesday, June 25, 2013 11:17:24 PM UTC-5, Louis Santillan wrote:
> So rugxulo & Rod are following.  I am looking to
> build DJGPP completely from scratch on a DOS box.
> If you reference typical GCC porting guides [1][2]
> [3][4], you start by building binutils, then GCC's
> deps (if using 3.x or later), then GCC, all using
> the typical ./configure && make && make install.

GNU is very POSIX oriented, so you need the appropriate
tools (Bash, Gawk, Grep, Make, CoreUtils) just to try
to build almost anything. It's not impossible, but
it's definitely not easy to bootstrap all of that.

I've built GCC 2.7.2.3 fairly easily before in pure
DOS, but I never tried the (SFN friendly?) BinUtils
2.9.5. Juan showed that libc is fairly easy to build,
but I haven't done a lot of that. 2.7.2.3 can build
later versions (2.95), allegedly, maybe even 3.4.x
(K&R support?).

It's not totally hopeless, and I'd even go so far as
to say I could (almost) be helpful (for once!). :-)
But I'm not sure how easy it will be overall.

I'm definitely interested, at least passively, but I
don't have the energy to rebuild everything myself!
But if you have a specific app you're stuck on,
feel free to ask questions (not that I'm an expert,
but it's certainly far from impossible).

[rug...@gmail.com]

Hi,

On Wednesday, June 26, 2013 3:05:30 AM UTC-5, Rod Pemberton wrote:
>
> > I don't know what "port MinGW to DOS" means,
> > but I'm very very skeptical.
>
> Basically, I was asking how difficult it would be to create a DOS
> only version of MinGW.

Which part? Presumably you mean borrowing (or using)
some parts of the libc. Or did you mean specific
tools? Or just support for compiling Windows programs?

I hate to say it, but overall it's probably too
complicated (and of dubious usefulness).

> If MSVCRT has many functions and MinGW
> uses many of them, it'll take much coding to remove or replace
> them. If the MSVCRT functions MinGW uses are complicated, not
> simple, it'll take even more work. Some C libraries only need
> about 20 functions to bootstrap, while others need many.

Do you want a DJGPP-hosted MinGW environment? Or are
you thinking of running some of this under HX?

> If yet another DOS C compiler is needed, it might be better to get
> the DOS versions of LCC, versions 3.5 and 3.6, working again.
> Then, migrate useable updates from 4.1 and 4.2 back.

Detlef Reimers already ported LCC 4.2 to DOS via DJGPP.
It uses NASM (COFF) and DJGPP's (BinUtils) ld linker
and older libc (2.01). He deleted his website, but I
could upload it somewhere for you. He also ported EiC
(interpreter) to DJGPP. (I would say "just email him",
but ....)

> Or, it might be better to de-Linux-ify TCC, e.g., remove the dlopen
> and dlsym related code, do test compiles with DJGPP, and figure out
> how to bootstrap later, perhaps with the old TurboC.

TinyC was originally Linux only, so it has some weird
kludges in there. IIRC, even on Win32 it used ELF
for .o files! It's not easy to rebuild (at least IMHO),
and when I tried with DJGPP, it didn't fully work
correctly.

Honestly, I think something like PCC would ideally be
better to port. But porting something like Nils Holm's
SubC (subset) is more realistic.

> If Japheth ignores it, rejects it, or doesn't have time for it,
> then I could package up one with the exe. Then, you could do me
> yet another favor and mirror it on your website (lol).

My Google Sites website isn't very useful. iBiblio mirror
of FreeDOS is a better idea, IMO, though it's all the
same to me.

> However, I
> was hoping the code could be reviewed by someone skilled in x86 and
> experienced with Himemx too, like Japheth, Devore, or some of the
> guys on DOSX, before being hosted on iBiblio, on Japheth's site, or
> on your site.

Of course, I thought the same (else I'd have already
mirrored it!). :-)

Tom Ehlert is still vaguely active, so maybe he'll
look at it, but outside of him, I don't know who else
would be interested. (Eric Auer seems absent these
days. Devore has been AWOL for a long time, but maybe
one of us could email him, if desperate.)

> My main concern is I can't test some of the really
> old machines HIMEMX works on. I also can't currently test the
> machine it was intended for. I may get it working by this fall.
> So, I just don't know if I introduced any unintended errors.

Japheth's already replied that he can't test multiple
blocks either.

Well, as long as it doesn't regress for current DOS
users, I guess that's as good as we can hope!

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:f54c7536-b2e9-46e0...@googlegroups.com...

> On Wednesday, June 26, 2013 3:05:30 AM UTC-5, Rod Pemberton
> wrote:

...

<OT>

> > If yet another DOS C compiler is needed, it might be better to
> > get the DOS versions of LCC, versions 3.5 and 3.6, working
> > again. Then, migrate useable updates from 4.1 and 4.2 back.
>
> Detlef Reimers already ported LCC 4.2 to DOS via DJGPP.
> It uses NASM (COFF) and DJGPP's (BinUtils) ld linker
> and older libc (2.01). He deleted his website, but I
> could upload it somewhere for you. He also ported EiC
> (interpreter) to DJGPP. (I would say "just email him",
> but ....)
>

Thanks for that mention. So, I downloaded that version of LCC too.
At some point, I may look at it.

Wow, I'd swear I saw his website previously. It's hard to
forget... Maybe it was in regards to EiC.
http://web.archive.org/web/20120109161243/http://detlefreimers.de/

Now, you're probably wondering how I found that without any
available reference to his non-existant website whatsoever... :-)
Try it. Go to Google and Yahoo. See if you can find it using only
"Detlef Reimers" and "Detlef Reimers lcc" as I did. Good luck.
;-)

> > Or, it might be better to de-Linux-ify TCC, e.g., remove
> > the dlopen and dlsym related code, do test compiles with
> > DJGPP, and figure out how to bootstrap later, perhaps
> > with the old TurboC.
>
> TinyC was originally Linux only, so it has some weird
> kludges in there. IIRC, even on Win32 it used ELF
> for .o files! It's not easy to rebuild (at least IMHO),
> and when I tried with DJGPP, it didn't fully work
> correctly.
>

Maybe, using DJELF and then DJGPP would be a better path.

TCC is interesting to me because it's small and fast.
LCC is interesting to me because it worked on DOS.

> Honestly, I think something like PCC would ideally be
> better to port.

PCC as in the original Portable C Compiler? Smile... :-)

Didn't one of the BSD projects attempt to resurrect it a few years
back as their default C compiler? AIR, they failed. IIRC, it has
a bunch of odd quirks, obsolete code, incomplete functionality,
etc. They might as well have chosen Tendra. It's probably far
more complete and upto date. Although, then they wouldn't have
had the prized BSD license...

> But porting something like Nils Holm's
> SubC (subset) is more realistic.

I seem to recall that I didn't like ... something ... about SubC,
but I don't have any idea of what it was or was in regards to.

> > My main concern is I can't test some of the really
> > old machines HIMEMX works on. I also can't currently test the
> > machine it was intended for. I may get it working by this
> > fall. So, I just don't know if I introduced any unintended
> > errors.
>
> Japheth's already replied that he can't test multiple
> blocks either.
>

Well, the existing functionality needs to be retested too. That's
just to confirm that all of it still works for various machines.
If all the retesting falls on me to do, it could be a while even
though I have a variety of machines. Not all of them are working
and some are packed away. I guess I was hoping that someone
maintaining HIMEMX had a test array of computers for regression
testing.

So, it may just be better to build it, package it, and list it as
experimental, or use at your own risk for now. I'll let you know
if I do upload it somewhere so you can grab it. Although, it is
easy to build.


Rod Pemberton

[rug...@gmail.com]

Hi,

On Thursday, June 27, 2013 4:40:04 AM UTC-5, Rod Pemberton wrote:
> <rug...@nospam.gmail.duh> wrote in message

I don't want to discourage you, but I don't know of
any perfect way to test. Even most of my older machines
have died (and I'm no repair guru), so I'm not much help
either.

There is no maintainer for FD HimemX. It hasn't been
touched in five years (outside of a small makefile
tweak). I guess it's considered stable by most people.
Or maybe they use other XMS drivers (FDXMS, XMGR).
Japheth apparently has little interest in working
on it directly, and emailing Devore shows similar
disinterest.

I mean, it's not totally hopeless, and as long as
regular DOS users can test in normal circumstances,
that's probably better than nothing. However, I'm
not sure who's up for even light testing. Presumably
everyone at BTTR and/or freedos-user.

Though thanks anyways for your efforts!

> So, it may just be better to build it, package it, and list it as
> experimental, or use at your own risk for now. I'll let you know
> if I do upload it somewhere so you can grab it. Although, it is
> easy to build.

I'm sure it's easy to build, but my weak attempts to
do so failed. (Well, the patch failed, which could mean
my own failure, but generally I know that such tools
are quite frail and picky, so I don't know.) I could
probably patch by hand if necessary. "It's always
something!" :-)

Anyways, I went ahead and uploaded to iBiblio. Feel
free to doublecheck it, correct it, build it, etc.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/

ftp://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/himem_rp.dif

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:fd61ee1c-d350-4961...@googlegroups.com...

> I don't want to discourage you, but I don't know of
> any perfect way to test. Even most of my older machines
> have died (and I'm no repair guru), so I'm not much help
> either.
>

For now, it'll have to be announced as experimental.

> I'm sure it's easy to build, but my weak attempts to
> do so failed. (Well, the patch failed, which could mean
> my own failure, but generally I know that such tools
> are quite frail and picky, so I don't know.) I could
> probably patch by hand if necessary. "It's always
> something!" :-)
>
> Anyways, I went ahead and uploaded to iBiblio. Feel
> free to doublecheck it, correct it, build it, etc.
>

Ok.

I packaged up a new version. It includes an executable, full asm
source, updated history, etc. I didn't package up Japheth's other
program he included in 332 that's part of JEMM.

The file is HIMEM334.ZIP:
http://www.filedropper.com/himem334

This is the MD5 checksum:
866e5d607f18b6bda49ab54f621d2e0f *himem334.zip

You'll have to enter a captcha to download it from filedropper. I
don't know how many downloads they allow. I also don't know how
long they allow it to be downloaded. I.e., it's probably best to
grab it and put it on iBiblio too.

Thanks.


Rod Pemberton

[rug...@gmail.com]

Hi,

On Tuesday, July 2, 2013 5:52:32 AM UTC-5, Rod Pemberton wrote:
> <rug...@spam.sux> wrote in message
>
> news:fd61ee1c-d350-4961...@googlegroups.com...
>

> > I'm sure it's easy to build, but my weak attempts to
> > do so failed.
>

> I packaged up a new version. It includes an executable, full asm
> source, updated history, etc.
>

> The file is HIMEM334.ZIP:
> http://www.filedropper.com/himem334
>
> This is the MD5 checksum:
> 866e5d607f18b6bda49ab54f621d2e0f *himem334.zip
>

> It's probably best to grab it and put it on iBiblio
> too.

Done, see below. Though I dislike long names, but I didn't
exactly want to just call it "himem334" because it's
experimental, unofficial, etc. IIRC, mTCP's FTP can
still grab it with something like "get longname short".
So that shouldn't be a huge problem.

BTW, I also mailed a quick message to freedos-devel in
the hopes that some people will help test for you. I
also pointed to the original post in the newsgroup
as preferred way to contact you.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/himem334-unofficial-rp.zip

[rug...@gmail.com]

Hi,

On Tuesday, July 2, 2013 5:52:32 AM UTC-5, Rod Pemberton wrote:
> <rug...@everyone.hates.spam> wrote in message
>
> news:fd61ee1c-d350-4961...@googlegroups.com...
>

> > I'm sure it's easy to build, but my weak attempts to
> > do so failed. (Well, the patch failed, which could mean
> > my own failure, but generally I know that such tools
> > are quite frail and picky, so I don't know.) I could
> > probably patch by hand if necessary. "It's always
> > something!" :-)
>

> Ok. I packaged up a new version.

Just for completeness (at always seeing such annoying issues), here's the deal:

=============================================
(Fri Jul 05, 11:09 AM) /tmp/doydoy # cat blah.sh
#!/bin/sh
md5sum [hH]imem*
sed -i~ -e '1,/BEGIN---cut-here--/d' -e '/END---cut-here--/,$d' himem_rp.dif
unzip -qja Himem332.zip SOURCE/HIMEMX.ASM
patch -l HIMEMX.ASM himem_rp.dif -o himemx.rod
unzip -qjao himem334-unofficial-rp.zip SOURCE/HIMEMX.ASM
diff -was HIMEMX.ASM himemx.rod

(Fri Jul 05, 11:10 AM) /tmp/doydoy # blah.sh
7ded523745ae836452402e402f02a11b Himem332.zip
866e5d607f18b6bda49ab54f621d2e0f himem334-unofficial-rp.zip
22ae67d811af236c5496c53e383a9b2b himem_rp.dif
patching file HIMEMX.ASM
Files HIMEMX.ASM and himemx.rod are identical
=============================================

I don't use patch as much as diff, hence why I wasn't
remembering the -l switch to ignore whitespace (same
as diff -w). But yes, also source and patch must
(apparently) match in line endings too. Instead of
manually running dos2unix, here I just let Info-Zip
fix that for me (-a to auto-convert).

This seems unavoidable, however, as some files (e.g.
GNU makefiles or Python or whatever) are sensitive
to changes in whitespace and might break otherwise.

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:2042449e-bcff-4329...@googlegroups.com...
> [RP]

> > It's probably best to grab it and put it on iBiblio
> > too.
>
> Done,

Thanks.

> see below. Though I dislike long names, but I didn't
> exactly want to just call it "himem334" because it's
> experimental, unofficial, etc. IIRC, mTCP's FTP can
> still grab it with something like "get longname short".
> So that shouldn't be a huge problem.
>

That's fine.

> BTW, I also mailed a quick message to freedos-devel in
> the hopes that some people will help test for you. I
> also pointed to the original post in the newsgroup
> as preferred way to contact you.
>

Thanks for that.

I forgot that was a email list. I did find it on Freedos.org.
It's probably available on Gmane too.

(Of course, the announcement probably need to be posted to
Freedos.org news to get anyone to try it... ;-)


RP

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:bf73996e-8743-4bf7...@googlegroups.com...

> Just for completeness (at always seeing such annoying issues),
> here's the deal:
>
> =============================================
> (Fri Jul 05, 11:09 AM) /tmp/doydoy # cat blah.sh
> #!/bin/sh
> md5sum [hH]imem*
> sed -i~ -e '1,/BEGIN---cut-here--/d' -e '/END---cut-here--/,$d'
> himem_rp.dif
> unzip -qja Himem332.zip SOURCE/HIMEMX.ASM
> patch -l HIMEMX.ASM himem_rp.dif -o himemx.rod
> unzip -qjao himem334-unofficial-rp.zip SOURCE/HIMEMX.ASM
> diff -was HIMEMX.ASM himemx.rod
>
> (Fri Jul 05, 11:10 AM) /tmp/doydoy # blah.sh
> 7ded523745ae836452402e402f02a11b Himem332.zip
> 866e5d607f18b6bda49ab54f621d2e0f himem334-unofficial-rp.zip
> 22ae67d811af236c5496c53e383a9b2b himem_rp.dif
> patching file HIMEMX.ASM
> Files HIMEMX.ASM and himemx.rod are identical
> =============================================
>

Uh, okay...

> I don't use patch as much as diff, hence why I wasn't
> remembering the -l switch to ignore whitespace (same
> as diff -w). But yes, also source and patch must
> (apparently) match in line endings too. Instead of
> manually running dos2unix, here I just let Info-Zip
> fix that for me (-a to auto-convert).
>
> This seems unavoidable, however, as some files (e.g.
> GNU makefiles or Python or whatever) are sensitive
> to changes in whitespace and might break otherwise.

Well, I tested the patch against a fresh unzip of Japheth's 3.32.
Of course, that was prior to me posting the patch, which may have
whitespace issues after posting... I didn't test the patch after
posting. But, I don't think that's an issue or hope it's not. (?)
This could be affected by your browser or editor too.

The posted patch is against Japheth's 3.32 assembly file which
doesn't have spaces at the end-of-line (EOL) trimmed. Using it
will result in a patched version of 3.32 (to 3.34) with whitespaces
untrimmed. I chose to do that because I had hoped Japheth
would host 3.34 and his prior versions have untrimmed whitespaces.

My source in the 3.34 zip has EOL whitespaces trimmed. IIRC, it
also has one section of text realigned slightly with space padding.

Anyway, you shouldn't need the -l for patch. You can use diff -w
to remove the effects of whitespace, when comparing the patched
source (3.32->3.34) and the source in 3.34 zip. All you should
have to do is unzip Japheth's 3.32 and run patch with the diff:

patch -p0 himemx.asm himemx.dif

(Where, himemx.asm is from Japheth's 3.32 and himemx.dif is the
posted diff without the delimiting lines.)

This process was mentioned in the comp.os.msdos.programmer post:
https://groups.google.com/d/msg/comp.os.msdos.programmer/jKuJKgUXRNU/6Rkm0bwB_iYJ

Then, once you have the new asm file, run build.bat, which is also
from Japheth's 3.32.
http://www.japheth.de/Jemm.html

As mentioned in the c.o.m.d. post, I used JWasm v2.10 (4/20/2013).
http://www.japheth.de/JWasm.html

Of course, you've got a zip now with a complete source file that's
both patched and trimmed of EOL whitespace. So, I'm not sure
exactly what your post is in regards to... i.e., the patch is
completely unecessary now.


Rod Pemberton

[rug...@gmail.com]

Hi,

On Saturday, July 6, 2013 10:55:26 AM UTC-5, Rod Pemberton wrote:
> <rug...@hates.spam> wrote in message
>
> news:2042449e-bcff-4329...@googlegroups.com...
>

> > BTW, I also mailed a quick message to freedos-devel
>

> (Of course, the announcement probably need to be posted to
> Freedos.org news to get anyone to try it... ;-)

I'm skeptical about how many people read such things,
but nevertheless, I've gone ahead and announced it
there too. Hope it helps.

[rug...@gmail.com]

Hi,

On Saturday, July 6, 2013 10:56:06 AM UTC-5, Rod Pemberton wrote:
> <rug...@spam.sux> wrote in message
>
> news:bf73996e-8743-4bf7...@googlegroups.com...
>

> Of course, you've got a zip now with a complete source file that's
> both patched and trimmed of EOL whitespace. So, I'm not sure
> exactly what your post is in regards to... i.e., the patch is
> completely unecessary now.

I just wanted to show exactly what I was experiencing.
Sometimes things don't go too smoothly. I wanted to
understand and explain exactly what was causing the
problem. It wasn't quite as simple as just running
patch. (Well, nothing's ever as easy as it seems.)

[Rod Pemberton]

<rug...@gmail.com> wrote in message
news:ec04489e-817a-435a...@googlegroups.com...

Thanks.

I did find a bug.

If you use the /MAX= parameter and set it to 4GB exactly (in KB),
then it won't clamp to 4GB correctly. I.e., this line, and AFAICT,
only this line, won't work:

/MAX=4194304

Changing 4194304 to 4194303 (or lower) does work. This is a 32-bit
overflow of eax by a shl.

I think the value just needs to be decremented by one for Himemx to
work correctly. But, this "new" machine (2009 parts just
assembled) is only mapping 2.8GB of my 4GB below the 4GB boundary
and pushing the remainder above 4GB! Unfortunately, the original
Himemx code *only* supports memory below the 4GB boundary. So,
this machine's third 001 E820 memory block above 4GB can't be
mapped by Himemx. The E820 map supports 64-bit addresses and
offsets. Himemx only support the lower 32-bits.

Since this machine isn't mapping a full 4GB below 4GB, I still
can't confirm if Himemx is clamped correctly to 4GB or not, just
that it's not clamping incorrectly for the /MAX=4194304 anymore.
So, maybe in the next week, I will adjust my fake BIOS E820 code
and attempt to see if I can confirm correct clamping by HIMEMX.
Sorry, I have yet to get the other old machine with AGP reassembled
to test it.

Anyway, for now, the one line code fix is indicated by FIX comment:

; clamp e820 memory to /MAX= memory limit, if set, and exit
mov eax,[_xms_max]
or eax,eax
je @@e820_loop ; no maximum XMS set
shl eax,10
dec eax ; FIX
cmp esi,eax
jbe @@e820_loop ; at or below maximum


Rod Pemberton