Hi Arkady, Tom,

> >      Isn't sy2pac open/free source?
> NO.
> > ... if no, then sy2pac usage may violate rules,
> > when this program used together with GPLed software.
> that's why HIMEM/EMM386 aren't GPL any longer.

I would like to add that this is perfectly okay for me...
FreeDOS software collection (base / edit / util / devel / net...)
contains software with various licenses, but most are open source.
Some programs are public domain, which means that you can do
whatever you want with the code... I would like to see the LSM
database to be CLARIFIED about whether or not the source code is
available for the public domain programs, though!
For example for TDSK, only sources of older versions are public,
so for practical matters, you can only spread but not modify the
binary of TDSK newer than version 2.3 ...

Other LSM database categories contain terms like "free" or "freeware"
without mentioning whether the sources are available - quite often
they are not, but e.g. for WatTCP and mime64 and val and vim they
are (LOADHI seems to be completely gone? And where is LOGON?)...
NRO sources are available, too, same for pdTree...
RERROR LSM is outdated, file is now at:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/
... and, just in case you were wondering, sources are available.
SPOOL LSM is outdated as well. Looks like somebody re-sorted ibiblio?
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/print/
is the path at the moment, and sources are available.

Whatever. Happy LSM database updating / clarifying.

And sorry that I misspelled SY2PACK...

Luckily, DEBUG of FreeDOS can hint about minimal CPU requirements,
so I typed "m0" and started analyzing... The stub contains 2 PUSHA,
2 POPA, one SHL AX,8 (?). All of those work on 186+. However, there
is ONE single instruction which requires a 386+ to work. Would be
nice if you could CHANGE that:

> 2E0FB2670A    LSS     SP,CS:[BX+0A] [needs 386]


Anyway, I found a PROBLEM which exists in the open source HIMEM code:

proc    initialize
    pushf
    push    eax ebx ecx edx esi edi
...
    call    check_cpu           ; do we have at least a 386?
    mov dx,offset no_386
        jnc     have_386
    jmp error_exit   
have_386:
...

Does not make much sense to add a 386 safety check AFTER having
used 32bit registers earlier in initialize. Plus the DOS 3.0+ and
the "XMS already installed" check might both be using 386+ style
jmp conditional near jumps: As a solution, they can jump conditionally
to the "jmp error_exit" line instead of directly to error_exit :-).

I think the recipe for an 186+ safe HIMEM *and* EMM386 would therefore
be:
- replace the LSS in the SY2PACK stub (can only be done by Tom)
- move the "call check_cpu" to the very start of "initialize" (with an
  pushf, push ax ... pop ax, popf around it, if needed)
- give the error exit for the "check_cpu failed" case a SEPARATE code
  thing (bypassing the "clear_table" code - it looks like you NEVER
  need "clear_table" after doing error_exit!? - and bypassing the line
  pop edi esi edx ecx ebx eax)
- avoid 386-optimizations in the C code for startup_exe / startup_driver
- call a CPU checker before jumping to TheRealMain of EMM386
  (at the moment, IS386() is called relatively late from TheRealMain)
- anything else that I might have forgotten

So you got one small fix in SY2PACK,
a bit of reordering of code in HIMEM,
and yet another bit of reordering or code (including replacement of
the C error message by an ASM one) in EMM386.

Let me know what kind of bribe-stuff you want for that :-P.

And remember: "waaaah!" (from "HIMEM64" sources).

Eric



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to