Hi,
[Moving to devel, in the understanding that this is more internal).
Michael Devore escribi�:
At 04:36 PM 3/13/2005 +0100, Bernd Blaauw wrote:
probably better, make HIMEM compatible to 286+, which would end up in a single unified XMS driver.
Adamantly and permanently opposed. And you might be too, with the potential size increase and performance decrease in HIMEM after the significant rewrite to regress the instruction set on all XMS 2.0 and admin code down from 32-bit registers to 16-bit. Nowadays I would just as soon write in 6502 or Z-80 assembly language as pure 16-bit 80x86 (except stubs), which is to say, only if somebody paid me to do it.
For the microscopic percentage of 80286-level clients, just use FDXMS286. Simple readily available solution. Fix it if it's broken, no big deal. Why mug HIMEM when it's so unnecessary?
I must say that I agree with you, at least in practical purposes.
The problem arises, formally, because the spec (http://fd-doc.sourceforge.net/spec/) is clear about XT compatibility.
There are other things about the spec that I also disagree. Furthermore, we are close to FD 1.0, and if current FD were released as 1.0 (bugs and todo list appart), we wouldn't even comply with the spec.
I know I might face opposition, but I think that this spec, made 10 years ago, was made when many less things about MS-DOS were made, and in a period where the processor/OS market was on another level. I believe that there are parts of the spec that deserve a major rework, not just patches.
In particular, and to mention some,
(1) (minor) "Microsoft will not develop DOS forever..." => "Microsoft ceased to develop DOS" (we know this well, after their WinME).
(2) I don't think MS-DOS 5.0 is an improvement over 3.3, even if you just watch the many differences in the LoL. Perhaps that is closer to be true if you say that versions after 5.0 are improvements (even with FAT32 support in 7.10). It is time to consider if we should specify that we are for MS-DOS 3.30 where the distributed kernel is closer to 5.0 (or to 7.10 I'd say)
(3) The forcing of 8088/80286 should perhaps become "strongly recommended" and not "mandatory"
(4) The necessity to comply with RBIL was questioned in this list time ago
(5) I personally agree that commands must compy with MS syntax, even if we distribute programs that have a completely different syntax (such as MEM or ctMOUSE)
(6) Date format: I guess it was made before NLS was better known to developers. I would replace it by "use NLS"
(7) Reference compilers: I continue to be BC3, whereas it was mentioned repeatedly in the list the convenience of OW. Same for NASM over MASM/TASM. Note however that this could become a "strongly recommended", because there are programs like EMM386 (TASM) or KEYB (TASM / TP) that are unlikely to change their code to reflect the spec.
(8) Perhaps the (TM) statement could go there too.
Just some ideas Aitor
------------------------------------------------------- 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
