For Rugxulo, questions for Japheth about the new version of HIMEMX

[Rod Pemberton]

Hey Rugxulo,

I noticed Japheth put out a new HIMEMX as mentioned on Robert
Riebisch's "DOS Ain't Dead" forum. Since I'm not subscribed there,
could you ask Japheth why he removed the attributions at the top of the
assembly file in version 3.34 for code fixes by Ninho, Mateusz Viste,
and Rod Pemberton (me) for his new v3.35? Yet, he left in the older
attributions prior to his 2007 attribution. It would seem from the
comments in v3.35 that he entirely wrote the E820h routine - as there
was no mention of me ...- but the v3.35 E820h code appears to mostly be
the version I significantly rewrote for v3.34, but it's just relocated
into it's old location. Of course, I'd need to compare v3.33, v3.34,
v3.35 in depth to be sure what I coded back then, but in the
attribution, it says "japheth 2020: - v3.34: added multiple int 15h,
ax=e820h memory block support" as if the E820h routine was entirely new.
Is he taking total claim to the E820h code in v3.35? ... I'm not really
concerned about this, but removal of those attributions would make more
sense if it was a 100% rewrite or complete removal of the prior E820h
code.

Also, I didn't check to see if Ninho's or Mateusz Viste's changes were
still present in v3.35, or if other changes I made were still there
(see link below). I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I suspect he
started from his code base, e.g., v3.33. That could imply that Ninho's
and Mateusz Viste's fixes, as well as my other fixes were lost going
from v3.34 to v3.35. These may be valuable to someone. Could he (or
did he) review these? Or, did he start with v3.34 instead of v3.33?

Let Japheth know that the first paragraph here summarizes my changes to
HIMEMX v3.34 better than the attributions:
https://groups.google.com/d/msg/comp.os.msdos.programmer/jKuJKgUXRNU/UinoCvvJ1FoJ

Also, IIRC, there was an off by one bug for the command line size if
the size was 4GB in v3.34. I don't recall where that fix was posted.

Feel free to post this in full or what you think needs to be passed
along to Japheth on "DOS Ain't Dead", but do mention it's via
comp.os.msdos.programmer on Usenet. In fact, you could just post a
link to this via Google Groups.


Rod Pemberton

[Rod Pemberton]

On Fri, 3 Apr 2020 02:43:53 -0500

Post by Rod Pemberton
Hey Rugxulo,
I noticed Japheth put out a new HIMEMX as mentioned on Robert
Riebisch's "DOS Ain't Dead" forum. Since I'm not subscribed there,
could you ask Japheth why he removed the attributions at the top of
the assembly file in version 3.34 for code fixes by Ninho, Mateusz
Viste, and Rod Pemberton (me) for his new v3.35? Yet, he left in the
older attributions prior to his 2007 attribution. It would seem from
the comments in v3.35 that he entirely wrote the E820h routine - as
there was no mention of me ...- but the v3.35 E820h code appears to
mostly be the version I significantly rewrote for v3.34, but it's
just relocated into it's old location. Of course, I'd need to
compare v3.33, v3.34, v3.35 in depth to be sure what I coded back
then, but in the attribution, it says "japheth 2020: - v3.34: added
multiple int 15h, ax=e820h memory block support" as if the E820h
routine was entirely new. Is he taking total claim to the E820h code
in v3.35? ... I'm not really concerned about this, but removal of
those attributions would make more sense if it was a 100% rewrite or
complete removal of the prior E820h code.
Also, I didn't check to see if Ninho's or Mateusz Viste's changes were
still present in v3.35, or if other changes I made were still there
(see link below). I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I suspect he
started from his code base, e.g., v3.33. That could imply that
Ninho's and Mateusz Viste's fixes, as well as my other fixes were
lost going from v3.34 to v3.35. These may be valuable to someone.
Could he (or did he) review these? Or, did he start with v3.34
instead of v3.33?
Let Japheth know that the first paragraph here summarizes my changes
https://groups.google.com/d/msg/comp.os.msdos.programmer/jKuJKgUXRNU/UinoCvvJ1FoJ
Also, IIRC, there was an off by one bug for the command line size if
the size was 4GB in v3.34. I don't recall where that fix was posted.
Feel free to post this in full or what you think needs to be passed
along to Japheth on "DOS Ain't Dead", but do mention it's via
comp.os.msdos.programmer on Usenet. In fact, you could just post a
link to this via Google Groups.

Personally, I'd like to see an E820h only version of HIMEMX. But, I
didn't have the time for that. Also, doing that would require an E820h
simulation TSR for older computers, e.g., pre-1996 BIOSes, i.e., ACPI
1.0 or so. This would need to grab info from the other older memory
methods (Int 12h, Int 15h AH=88h, Int 15h AH=8Ah, Int 15h AH=C7h, Int
15h AX=DA88h, Int 15h AX=E801h) and would need to construct a fake E820h
map and install the E820h interrupt. Some of those access the CMOS
or BDA 40:13h. No one seems to know how to call DA88h. Or, older
computer users could just use an older version of HIMEMX ... And, this
computer is almost a decade old now too. I s there any point to any of
this everything is UEFI now? ... I s everything UEFI now or can you
still buy a BIOS based motherboards? Anyone build a new computer in the
last couple of years?


Rod Pemberton

[r***@gmail.com]

Hi,

Post by Rod Pemberton
On Fri, 3 Apr 2020 02:43:53 -0500
Or, older computer users could just use an older version of HIMEMX ...
And, this computer is almost a decade old now too.

My main Lenovo desktop (2011) and Dell laptop (2010) are similarly
"old", too. (No VT-X hurts the laptop quite a bit, but at least
I can boot FreeDOS natively via USB jump drive.)

Post by Rod Pemberton
Is there any point to any of this everything is UEFI now?

I don't know, there's too many (old and new) machines. Seriously,
it's hard to even pretend to know what to buy sometimes.

Yes, Intel supposedly wants to kill CSM (and BIOS) this year,
but I haven't read any official statements. This is probably
related to power management and better battery life. Or maybe
they just don't want the maintenance burden when only few use it
(sadly).

But VT-X is (apparently) ubiquitous on newer hardware, so at
least we can run under a VM without horrible bugs and slowdown.
(Even this Chromebook has it and can optionally run "Linux (beta)"
cmdline stuff under QEMU/KVM.)

Actually, VirtualBox has deprecated (will soon drop) 32-bit
hosts (5.x) *and* cpus without hardware VT-X extensions (6.0.x).
So that's ... "good"???

Post by Rod Pemberton
Is everything UEFI now or can you still buy a BIOS based motherboards?
Anyone build a new computer in the last couple of years?

I'm too dumb to build my own, and I'm not a professional, nor rich.
So my input is fairly limited, unfortunately.

I was looking online at various Linux laptops and even some
Dell (Win10) laptops. (WSL2 is based upon Hyper-V and requires VT-X,
apparently.) Even DOSEMU2 can optionally use VT-X nowadays, allegedly.

Actually, everybody is raving mad about AVX2 (ahem, Fedora),
circa 2013/2015, although FASM dude says it only works in 16-bit
pmode (for us), which isn't popular. In fact, I've seen very
little SSE2 code for DOS, much less AVX! (I still don't have
any AVX machines, and it seems Intel is still not shipping it
on anything that isn't high-end.)

Actually, AMD Ryzen (Zen 3 coming soon??) is all the rage.
So that's what a lot of people prefer nowadays. Not for
DOS, obviously, but again, VT-X and hypervisors are probably
our best bet (outside of refurbished "slightly older" stuff).

* https://www.newegg.com/p/1TS-000E-0AFB6
(used Lenovo Thinkpad, Zorin w/ WINE, older AMD dual-core)

No idea if it has a native BIOS for USB booting, but
presumably DOSEMU2 would work. Oh, and "only" 4 GB
of RAM (but most Linux distros and software seem to
be dropping 32-bit editions, which are probably more
conservative in RAM usage due to smaller pointers).
So I dunno how well that will work. (AFAIK, this
Chromebook is only 4 GB but x64. It works okay,
but I don't do any heavy lifting with it.)

At least there'll be Ubuntu LTS (x64 only?) very soon!

BTW, what about some of these?

* https://starlabs.systems/
* https://thelinuxlaptop.com/
* https://system76.com/

(Sorry if that's almost off-topic, but old hardware just doesn't
last, and I don't care for Windows at all. But I'm almost the
worst person to ask about modern Linux or hardware.)

[Steve Nickolas]

On Wed, 8 Apr 2020, ***@gmail.com wrote:

<snip>

Post by r***@gmail.com
Yes, Intel supposedly wants to kill CSM (and BIOS) this year,
but I haven't read any official statements. This is probably
related to power management and better battery life. Or maybe
they just don't want the maintenance burden when only few use it
(sadly).
But VT-X is (apparently) ubiquitous on newer hardware, so at
least we can run under a VM without horrible bugs and slowdown.
(Even this Chromebook has it and can optionally run "Linux (beta)"
cmdline stuff under QEMU/KVM.)
Actually, VirtualBox has deprecated (will soon drop) 32-bit
hosts (5.x) *and* cpus without hardware VT-X extensions (6.0.x).
So that's ... "good"???

I've thought of making an OS for 64-bit UEFI PCs which is designed to be
backward compatible, by any means, with MS-DOS - but that's way out of my
league.

I mean, I could provide guidance to someone who wants to get it off the
ground, but that's the best I could do as I'm not well-versed in low-level
matters.

-uso.

[T. Ment]

Post by Steve Nickolas
I've thought of making an OS for 64-bit UEFI PCs which is designed to be
backward compatible, by any means, with MS-DOS - but that's way out of my
league.

Why would anyone bother. No market for it.

Post by Steve Nickolas
I mean, I could provide guidance to someone who wants to get it off the
ground, but that's the best I could do as I'm not well-versed in low-level
matters.

For guidance, there's Undocumented DOS, DOS Internals, and many other
books. But they have errors, contradictions, and some of their code is
buggy. Sorting it out would take longer than human life span allows.

[Mateusz Viste]

(...) I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I suspect he
started from his code base, e.g., v3.33.

I looked at his HimemX code a week ago, and that's the conclusion
I came to as well. Seems he ignored the newer changes and re-did them
by himself (or so I hope). Interestingly, he replaced Ninho's JMP+02
fix necessary for old 386SX machines by a JZ+02 variant.

I was planning to import his version to "our" branch at himemx.sf.net,
but the amount of differences made me drop that idea.

Let Japheth know that the first paragraph here summarizes my changes
https://groups.google.com/d/msg/comp.os.msdos.programmer/jKuJKgUXRNU/UinoCvvJ1FoJ

Also a good overview is available in the svn history of the sf himemx
project - I took care few years ago to format each patch and apply them
in a consistent way, providing attributions whenever I could:

https://sourceforge.net/p/himemx/code/commit_browser

I'd be glad to apply Japheth's patches there, if they are indeed
improvements, but someone would have to sort them out first...

Mateusz

[T. Ment]

Post by Mateusz Viste

(...) I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I suspect he
started from his code base, e.g., v3.33.

Any attribution to Rod would scare me. He's the guy who told you to mess
around with sp:

xchg bp,sp

2019-10-01 (How to modify values placed on the stack?) a.l.a

Post by Mateusz Viste
I looked at his HimemX code a week ago, and that's the conclusion
I came to as well. Seems he ignored the newer changes and re-did them
by himself (or so I hope)

There's no copyright on ideas. No need to scare people by attributing
amateur tweakers.

[Rod Pemberton]

On Fri, 03 Apr 2020 15:20:06 +0000

Post by T. Ment

(...) I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I
suspect he started from his code base, e.g., v3.33.

Any attribution to Rod would scare me. He's the guy who told you to
xchg bp,sp
2019-10-01 (How to modify values placed on the stack?) a.l.a

<OT, reply to T.Ment's recent attacks ...>

It seems that you've been going off-topic on a variety of groups in an
attempt to incite or provoke others. Is that correct?

Also, it seems that you cherry-pick details both here and elsewhere
(a.l.a., a.o.d., etc) in an attempt to attack me or impugn my
reputation. Most of these claims are misleading, deceptive,
distortions, and simplifications, as they are usually presented without
context, or the context is just ignored by you.

As well discussed in that conversation, he was working on an 8088 which
doesn't generate the interrupts necessary to cause this to fail. The
issues which could cause a failure were exceptionally unlikely to occur,
and the OP was wanting the absolute fasted possible solution. That was
taken to be a requirement. This was about speed, not safety, not
long-term compatibility. I.e., you (and others) ignored the necessary
constraints.

So, I'm far more concerned that you were unaware of the differences
across processor designs over the decades. You're far more likely to
code something for a modern processor that fails on an older one.

AISI, your arguments against me are specious at best.

So, are you done with the personal attacks now? (Ad Hominem)... Can we
get back to programming? What about on-topic conversation?

Post by T. Ment
There's no copyright on ideas.

There is copyright on the expression of ideas.

Post by T. Ment
No need to scare people by attributing amateur tweakers.

There is also no need to scare people by falsely accusing people of
being "amateur" and "tweaker" either.

My guess is everyone who contributed to HIMEMX could be classified as
either "amateur" or "tweaker" by an outside observer like you. Ditto
Linux. Ditto Firefox. The criterion here is a) were they intelligent
and skilled enough to get the job done and b) does it work correctly.
The source code I contributed is open for anyone to review and fix if
there are errors, including by you.


Rod Pemberton

[T. Ment]

Post by Rod Pemberton
The source code I contributed is open for anyone to review and fix if
there are errors, including by you.

If Japheth didn't waste his time, why would I.

[Rod Pemberton]

On Fri, 03 Apr 2020 22:08:57 +0000

Post by T. Ment

Post by Rod Pemberton
The source code I contributed is open for anyone to review and fix
if there are errors, including by you.

...

Post by T. Ment
If Japheth didn't waste his time, why would I.

This question without a question mark, can be answered in many ways.

Post by T. Ment
If Japheth didn't waste his time, why would I.

If Japheth ignored the contributions of others, why shouldn't you do
so as well? I think that was what you should've said, truly.

Post by T. Ment
If Japheth didn't waste his time, why would I.

Look, I probably have as much respect for Japheth's coding skills as
you do. The "probably" is mainly because I don't know his real
identity and a bit because I do more C programming than assembly. I.e.,
if he's some incompetent asshole from my past, which is very unlikely,
then he doesn't get any credit. So, he's very likely to be glorified
in my eyes, should his identity become known.

Post by T. Ment
If Japheth didn't waste his time, why would I.

It seems that you'd prefer to not have fixes by three people,
preferring to use a version without them? That's insane. And, it's
impolite to blame your insanity and irrationality upon others, as
you've done to Japheth here. That is of course bizarre, as it's clear
that you respect him.

Post by T. Ment
If Japheth didn't waste his time, why would I.

As noted earlier in the thread, I'm not the only one who is wondering
why Japheth made the choices he has. Maybe, he didn't like the coding
style of other contributors, which I preserved. Maybe, he preferred to
resume where he left off nearly a decade ago. Who knows, but him,
which is why I asked. However, it seems counterproductive and
uncooperative to the spirit of open-source software to (presumptively)
revert to an earlier code version without the fixes contributed by
three other people in the mean time. That could imply his recent
version is broken in some manner.

And, we're still waiting apparently for the message to be passed on to
him as I'm not on the platform where he posted.


Rod Pemberton

[T. Ment]

Post by Rod Pemberton
As noted earlier in the thread, I'm not the only one who is wondering
why Japheth made the choices he has. Maybe, he didn't like the coding
style of other contributors, which I preserved. Maybe, he preferred to
resume where he left off nearly a decade ago. Who knows, but him,
which is why I asked. However, it seems counterproductive and
uncooperative to the spirit of open-source software to (presumptively)
revert to an earlier code version without the fixes contributed by
three other people in the mean time. That could imply his recent
version is broken in some manner.

To me it says the three "fixers" don't know what they're doing.

[r***@gmail.com]

Hi, Rod,

I noticed Japheth put out a new HIMEMX [3.35]

There are two variations, and I've only (minimally) tested HimemX2.
I have no idea if he ever intends to merge the two (apparently not).
Regressions are bad, but so far I haven't seen any.

could you ask Japheth why he removed the attributions at the top of the
assembly file in version 3.34 for code fixes by Ninho, Mateusz Viste,
and Rod Pemberton (me) for his new v3.35? Yet, he left in the older
attributions prior to his 2007 attribution.

Dunno. If it bothers you, you (we?) can fork it and add it back.
I can mirror files to iBiblio for FreeDOS, if that helps.

Some people may shun forking, but sometimes it's a good thing.
Let's not be too much against the idea, if it helps.

It would seem from the
comments in v3.35 that he entirely wrote the E820h routine - as there
was no mention of me ...- but the v3.35 E820h code appears to mostly be
the version I significantly rewrote for v3.34, but it's just relocated
into it's old location. Of course, I'd need to compare v3.33, v3.34,
v3.35 in depth to be sure what I coded back then, but in the
attribution, it says "japheth 2020: - v3.34: added multiple int 15h,
ax=e820h memory block support" as if the E820h routine was entirely new.
Is he taking total claim to the E820h code in v3.35? ... I'm not really
concerned about this, but removal of those attributions would make more
sense if it was a 100% rewrite or complete removal of the prior E820h
code.

I suspect he just hasn't fully tested it yet. Maybe he's waiting for
end users to do some testing for him across various machines. Or
maybe he's just tired. No idea. With such legacy software and almost
40 years of IBM PCs, it's going to be hard to test everything,
especially something so low-level.

I almost regret not having more physical machines for testing stuff
like this, but there's too many (and old/broken is "bad"), so I haven't
bought a lot of hardware lately (plus I'm fairly noobish overall).
I mean, I did buy a low-end Chromebook, but that's not much help.
Maybe I need to get a refurbished laptop from NewEgg, dunno.
(My desktop and laptop are quite old by now.)

Also, I didn't check to see if Ninho's or Mateusz Viste's changes were
still present in v3.35, or if other changes I made were still there
(see link below). I suspect that maybe he didn't see the newer
attributions, since they were probably only in v3.34, and I suspect he
started from his code base, e.g., v3.33. That could imply that Ninho's
and Mateusz Viste's fixes, as well as my other fixes were lost going
from v3.34 to v3.35. These may be valuable to someone. Could he (or
did he) review these? Or, did he start with v3.34 instead of v3.33?

I don't know. We need more testers. At worst, we just revert back to
using older 3.34. I don't know his motivations or target audience, if
any. He's maybe just scratching an itch and not trying to solve 100%
of all potential technical problems.

Let Japheth know that the first paragraph here summarizes my changes to
https://groups.google.com/d/msg/comp.os.msdos.programmer/jKuJKgUXRNU/UinoCvvJ1FoJ

I did just now post a mention that you were discussing it here.
(Sorry I'm late, but there isn't much activity here, so I don't
check it as much. Plus it's easy to be distracted with other
software issues, etc.)

Also, IIRC, there was an off by one bug for the command line size if
the size was 4GB in v3.34. I don't recall where that fix was posted.

I think I was using Mateusz's HimemX "cleaned up" 3.34 build from 2015
until recently, which seemingly worked fine. I have HimemX2 3.35
from Japheth as default now (on one FreeDOS USB jump drive) but
can't test literally everything, obviously.

Feel free to post this in full or what you think needs to be passed
along to Japheth on "DOS Ain't Dead", but do mention it's via
comp.os.msdos.programmer on Usenet. In fact, you could just post a
link to this via Google Groups.

I did link to here, so hopefully he chimes in. But even he may have
other priorities or may be tired or just disinterested. We probably
shouldn't get our hopes up too high. Perfectionism is great in
such highly delicate software, but we're just too understaffed
(so to speak). Sorry if I can't help more.

Thanks for your efforts, though.