Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Freedos-user] Any interest in 486, 586, 686 kernels?

Louis Santillan
So I made changes to the following files

config.b
* Added recognition of new CPU arch's
* Keep from clobbering arguments when using buildall.bat

build.bat
* Added recognition of new CPU arch's

buildall.bat
* Added new CPU arch's as build targets

mkfiles/generic.mak
* Added recognition of new CPU arch's and translation to wcc options

mkfiles/watcom.mak
* Added new CPU arch's to fallback arch test

These are the kernels that get compiled out of buildall.bat
KWC18616 MAP        84,748  05-02-2013  7:55p
KWC18616 SYS        63,028  05-02-2013  7:55p
KWC18632 MAP        84,977  05-02-2013  7:55p
KWC18632 SYS        67,180  05-02-2013  7:55p
KWC28616 MAP        84,748  05-02-2013  7:55p
KWC28616 SYS        63,028  05-02-2013  7:55p
KWC28632 MAP        84,977  05-02-2013  7:55p
KWC28632 SYS        67,180  05-02-2013  7:55p
KWC38616 MAP        87,053  05-02-2013  7:54p
KWC38616 SYS        62,164  05-02-2013  7:54p
KWC38632 MAP        87,282  05-02-2013  7:54p
KWC38632 SYS        66,044  05-02-2013  7:54p
KWC48616 MAP        84,748  05-02-2013  7:54p
KWC48616 SYS        62,068  05-02-2013  7:54p
KWC48632 MAP        84,977  05-02-2013  7:54p
KWC48632 SYS        65,948  05-02-2013  7:54p
KWC58616 MAP        84,748  05-02-2013  7:54p
KWC58616 SYS        62,068  05-02-2013  7:54p
KWC58632 MAP        84,977  05-02-2013  7:54p
KWC58632 SYS        65,948  05-02-2013  7:54p
KWC68616 MAP        84,748  05-02-2013  7:53p
KWC68616 SYS        62,068  05-02-2013  7:53p
KWC68632 MAP        84,977  05-02-2013  7:53p
KWC68632 SYS        65,948  05-02-2013  7:53p
KWC8616  MAP        84,748  05-02-2013  7:56p
KWC8616  SYS        64,158  05-02-2013  7:56p
KWC8632  MAP        84,977  05-02-2013  7:55p
KWC8632  SYS        68,358  05-02-2013  7:55p

-L

-L



On Thu, May 2, 2013 at 11:48 PM, Eric Auer <[hidden email]> wrote:

Hoi Louis,

please explain the hack / patch: Is the only thing that
you changed that the kernel is compiled for those CPUs?
Are there actually any differences between them? I can
imagine that OpenWatcom makes 186 and 286 the same and
everything above 386 the same. Unless the kernel would
contain heavy mathematical processing for which it is
obvious that above-386 optimizes better ;-) You could
tell the compiler to produce Assembly output (instead
of binary) and compare the text. Or you could use some
debug, disassembler (ndisasm?) or hex editor to compare
before you UPX things, but of course that is more work.

Thanks for comparing :-) Maybe this is more a topic for
the kernel list. Note that if "a few" bytes are really
only 10 or so, all this is probably more an "academic"
exercise. Things get more exciting once you can save at
least a cluster of disk space or a paragraph of RAM :-)

Regards, Eric

> I hacked the 2041 kernel batch and make files included on the FD 1.1 iso to
> allow the kernel to be built by OpenWatcom as 8086, 186, 286, 386, 486,
> 586, or 686.  The resulting 686 kernel boots fine in VirtualBox 4.2.12 in
> OSX 10.8.3 on my 2012 Mac Book Air 13" 4GB.  The resulting kernel is a few
> bytes smaller compressed by upx than kernel installed by the FD 1.1 iso.
>  I'm going to continue testing.  No source changes were made.  Not sure how
> the changes affect the nasm built files.




------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Eric Auer-3

Hi Louis,

if I understand your patch correctly, you only changed the
build configuration to check how it affects the size of
the compiled kernel before UPX compression, which also is
an indicator of RAM size of the kernel? You changed the
config.b, build.bat, buildall.bat files and generic.mak
and watcom.mak and the resulting kernel sizes give the
impression that in fact you only have FOUR distinct CPU
optimizations, rather than seven cases...

Kernels without FAT32:

086: 64158 bytes
186: 63028 bytes (286 same)
386: 62164 bytes
486: 62068 bytes (586 and 686 same)

Kernels with FAT32:

086: 68358 bytes
186: 67180 bytes (286 same)
386: 66044 bytes
486: 65948 bytes (586 and 686 same)



It is interesting that even 186 instructions do make a
quite big difference and that there is a difference at
all between 386 and 486. With 186, you get pusha and
popa, shift/rotate by fixed numbers of bits. some mul
extensions, enter/leave and I/O strings and some more
exotic things. I think even I/O strings are not used
at all for the kernel. Everything added in 286 is for
protected mode, so 186 and 286 are exactly the same
kernels because DOS runs in real mode ;-)

In the past, we compiled kernels for 8086, 186 and
386 separately afair. I guess we got lazy and have
dropped 186 because very few users have 186/286 as
their CPU? They either have modern or REALLY old.

Also, we keep offering 8086 compiles for the sake
of good old times and for people with emulators.



The 386 optimization is useful and we already used
it: Having 32 bit computations helps even for DOS.
There are also some new bit string opcodes, SETCC
(conditional set a byte) JCXZ and near conditional
jumps and loops that are supported starting at 386.

Your 486 to 686 kernels are the same size and 486s
only XADD and BSWAP (and CMPXCHG). It is impressive
that those actually make any (100 byte) difference!

Maybe your compiles assume that 486 does and 386
does not have FPU? That would not be very accurate.



As with 286, the news in 586 is mostly protected
mode related (simply speaking). Neither CMPXCHG8B
nor the time stamp counter nor CPUID bothers DOS.

The main news in 686 would be CMOV, a conditional
MOV, but looking only at kernel sizes, it is likely
that the compiler just does not use CMOV for 686.
It is odd to get exactly the same size otherwise.



For even newer CPU, you could use FPU and vector
(MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
but it is highly unlikely that those make any DOS
difference. At most they could speed up memmove.

There are also some string comparison / bit count
things in SSE4, but the overhead to use them is
probably higher than the benefit in DOS context.
DOS is not math-heavy, so even a classic like a
fused multiply add is unlikely to optimize DOS.

This mail uses www.sandpile.org and
http://en.wikipedia.org/wiki/X86_instruction_listings#Added_in_specific_processors
as information sources :-)

Regards, Eric



------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Louis Santillan
On Fri, May 3, 2013 at 4:02 AM, Eric Auer <[hidden email]> wrote:

Hi Louis,

if I understand your patch correctly, you only changed the
build configuration to check how it affects the size of
the compiled kernel before UPX compression, which also is
an indicator of RAM size of the kernel? You changed the
config.b, build.bat, buildall.bat files and generic.mak
and watcom.mak and the resulting kernel sizes give the
impression that in fact you only have FOUR distinct CPU
optimizations, rather than seven cases...

Yes.  And just ran md5sum's against the kernels to verify this

3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
623498bd71a46d16bcef211e743a9bed  kwc38616.sys
c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

69eb7732f791db340632f722c9dbce16  kwc8632.sys
f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
1e4fd656603fd09171d9d85631e77045  kwc28632.sys
b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't know much about 586+ arch's but can use the instructions in special situations.  And this makes sense when you consider when Watcom fell out of favor commercially and probably saw it's last real optimizer work.
 
Kernels without FAT32:

086: 64158 bytes
186: 63028 bytes (286 same)
386: 62164 bytes
486: 62068 bytes (586 and 686 same)

Kernels with FAT32:

086: 68358 bytes
186: 67180 bytes (286 same)
386: 66044 bytes
486: 65948 bytes (586 and 686 same)

[SNIP] 

 Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions.  But just an idea right now.

-L

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Louis Santillan
What's the difference between wcc & wcc386?  I noticed that wcc386 adds -5s, -5r, -fp5 (-6 equivalents) for stack, register and fpu optimization.  Does wcc386 generate code that could be used in the kernel?

-L


On Fri, May 3, 2013 at 5:57 AM, Louis Santillan <[hidden email]> wrote:
On Fri, May 3, 2013 at 4:02 AM, Eric Auer <[hidden email]> wrote:

Hi Louis,

if I understand your patch correctly, you only changed the
build configuration to check how it affects the size of
the compiled kernel before UPX compression, which also is
an indicator of RAM size of the kernel? You changed the
config.b, build.bat, buildall.bat files and generic.mak
and watcom.mak and the resulting kernel sizes give the
impression that in fact you only have FOUR distinct CPU
optimizations, rather than seven cases...

Yes.  And just ran md5sum's against the kernels to verify this

3c0d2507d2595727b6d9a9a1bc979e72  kwc8616.sys
40d4679c99cd2579d0a96acdaaa62d99  kwc18616.sys
2234e5d367fb2562f430bc84dafd5c7d  kwc28616.sys
623498bd71a46d16bcef211e743a9bed  kwc38616.sys
c3a607792ba8a0c8c8705dd370180619  kwc48616.sys
c3a607792ba8a0c8c8705dd370180619  kwc58616.sys
c3a607792ba8a0c8c8705dd370180619  kwc68616.sys

69eb7732f791db340632f722c9dbce16  kwc8632.sys
f5c6d0d778fb196610385bc7c4689419  kwc18632.sys
1e4fd656603fd09171d9d85631e77045  kwc28632.sys
b51d670433fd5d0d31d7babecbed84fe  kwc38632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc48632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc58632.sys
e1e87c09787ea3db18ccaa5c1675420a  kwc68632.sys

...and I'll modify Eric's assertion.  There's 5 kernel produced by OW for the 7 arch's.  x86, 186, 286, 386, 486+.  It would seem that OW doesn't know much about 586+ arch's but can use the instructions in special situations.  And this makes sense when you consider when Watcom fell out of favor commercially and probably saw it's last real optimizer work.
 
Kernels without FAT32:

086: 64158 bytes
186: 63028 bytes (286 same)
386: 62164 bytes
486: 62068 bytes (586 and 686 same)

Kernels with FAT32:

086: 68358 bytes
186: 67180 bytes (286 same)
386: 66044 bytes
486: 65948 bytes (586 and 686 same)

[SNIP] 

 Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm in the kernel now and possibly the string functions.  But just an idea right now.

-L


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

tom ehlert
In reply to this post by Eric Auer-3
> Kernels with FAT32:

> 086: 68358 bytes
> 186: 67180 bytes (286 same)
> 386: 66044 bytes
> 486: 65948 bytes (586 and 686 same)



> It is interesting that even 186 instructions do make a
> quite big difference and that there is a difference at
> all between 386 and 486. With 186, you get pusha and
> popa, shift/rotate by fixed numbers of bits.
ENTER
LEAVE

> In the past, we compiled kernels for 8086, 186 and
> 386 separately afair. I guess we got lazy and have
> dropped 186 because very few users have 186/286 as
> their CPU? They either have modern or REALLY old.
this is not about 'lazy'
it's easier for the user to select between 2 choices then between
4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.

there's not much use for a 186 kernel as NOBODY has 186/286 machines
these days,

> Also, we keep offering 8086 compiles for the sake
> of good old times and for people with emulators.



> The 386 optimization is useful and we already used
> it: Having 32 bit computations helps even for DOS.
> There are also some new bit string opcodes, SETCC
> (conditional set a byte)
nothing of this is used by the compiler

>  JCXZ
was always supported

>  and near conditional
> jumps and loops that are supported starting at 386.
*far* conditional jumps started with 386.

however what *IS* used by wcc is
   the additional FS and GS register
some (few)
 push DWORD constant

what would be useful, but is not used by WCC
 dword arithmetic
filesystem code uses long variables everywhere



> Your 486 to 686 kernels are the same size and 486s
> only XADD and BSWAP (and CMPXCHG). It is impressive
> that those actually make any (100 byte) difference!

strange enough, compiling here with -3 and -6 makes exactly no
difference. using watcom 1.9

could you post the compiled files, or even

  for %i in (*.obj) do wdis -l -a -s %i

for -3 and -6 and show us the differences ?


> Maybe your compiles assume that 486 does and 386
> does not have FPU? That would not be very accurate.
pointless as the kernel doesn't use any FPU code



> As with 286, the news in 586 is mostly protected
> mode related (simply speaking). Neither CMPXCHG8B
> nor the time stamp counter nor CPUID bothers DOS.


> The main news in 686 would be CMOV, a conditional
> MOV, but looking only at kernel sizes, it is likely
> that the compiler just does not use CMOV for 686.
> It is odd to get exactly the same size otherwise.
it doesn't use cmov


> For even newer CPU, you could use FPU and vector
> (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
> SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
> but it is highly unlikely that those make any DOS
> difference. At most they could speed up memmove.
as the kernel doesn't much memcpy/memmove, you can't accelerate it
by any significant amount.otherwise we *would* have
  rep movsD

tom


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

tom ehlert
In reply to this post by Louis Santillan

> What's the difference between wcc & wcc386?
code generation for 16 bit (DOS) or 32 bit (windows)

>  Does wcc386 generate code that could be used in the kernel?
no

>>  Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
>> in the kernel now and possibly the string functions.  But just an idea
>> right now.
the kernel doesn't copy (much). nothing to be gained.

tom


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Louis Santillan
In reply to this post by tom ehlert
I'll have to post my files when I get back from Disneyland tonight.  Some initial thoughts about the byte savings, things like LEA got and loop unrolling got super efficient with later processors.  It wasn't just about the new instructions but upgrades & new forms of old instructions. TASM used to be real good about picking efficient opcodes.

-L

On Friday, May 3, 2013, Tom Ehlert wrote:
> Kernels with FAT32:

> 086: 68358 bytes
> 186: 67180 bytes (286 same)
> 386: 66044 bytes
> 486: 65948 bytes (586 and 686 same)



> It is interesting that even 186 instructions do make a
> quite big difference and that there is a difference at
> all between 386 and 486. With 186, you get pusha and
> popa, shift/rotate by fixed numbers of bits.
ENTER
LEAVE

> In the past, we compiled kernels for 8086, 186 and
> 386 separately afair. I guess we got lazy and have
> dropped 186 because very few users have 186/286 as
> their CPU? They either have modern or REALLY old.
this is not about 'lazy'
it's easier for the user to select between 2 choices then between
4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.

there's not much use for a 186 kernel as NOBODY has 186/286 machines
these days,

> Also, we keep offering 8086 compiles for the sake
> of good old times and for people with emulators.



> The 386 optimization is useful and we already used
> it: Having 32 bit computations helps even for DOS.
> There are also some new bit string opcodes, SETCC
> (conditional set a byte)
nothing of this is used by the compiler

>  JCXZ
was always supported

>  and near conditional
> jumps and loops that are supported starting at 386.
*far* conditional jumps started with 386.

however what *IS* used by wcc is
   the additional FS and GS register
some (few)
 push DWORD constant

what would be useful, but is not used by WCC
 dword arithmetic
filesystem code uses long variables everywhere



> Your 486 to 686 kernels are the same size and 486s
> only XADD and BSWAP (and CMPXCHG). It is impressive
> that those actually make any (100 byte) difference!

strange enough, compiling here with -3 and -6 makes exactly no
difference. using watcom 1.9

could you post the compiled files, or even

  for %i in (*.obj) do wdis -l -a -s %i

for -3 and -6 and show us the differences ?


> Maybe your compiles assume that 486 does and 386
> does not have FPU? That would not be very accurate.
pointless as the kernel doesn't use any FPU code



> As with 286, the news in 586 is mostly protected
> mode related (simply speaking). Neither CMPXCHG8B
> nor the time stamp counter nor CPUID bothers DOS.


> The main news in 686 would be CMOV, a conditional
> MOV, but looking only at kernel sizes, it is likely
> that the compiler just does not use CMOV for 686.
> It is odd to get exactly the same size otherwise.
it doesn't use cmov


> For even newer CPU, you could use FPU and vector
> (MMX, SSE, SSE2, SSE3, SSE4a, EMMX, 3dNow, 3dNow+,
> SSE4.1, SSE4.2, AVX FMA, not AES ;-)) instructions
> but it is highly unlikely that those make any DOS
> difference. At most they could speed up memmove.
as the kernel doesn't much memcpy/memmove, you can't accelerate it
by any significant amount.otherwise we *would* have
  rep movsD

tom


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Freedos-kernel@lists.sourceforge.net&#39;)">Freedos-kernel@...
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Hans-2
In reply to this post by tom ehlert
On 03/05/2013 15:55, Tom Ehlert wrote:

>> In the past, we compiled kernels for 8086, 186 and
>> 386 separately afair. I guess we got lazy and have
>> dropped 186 because very few users have 186/286 as
>> their CPU? They either have modern or REALLY old.
> this is not about 'lazy'
> it's easier for the user to select between 2 choices then between
> 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
>
> there's not much use for a 186 kernel as NOBODY has 186/286 machines
> these days,
Really, NOBODY.....

Hans
www.ht-lab.com




------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|

Re: Any interest in 486, 586, 686 kernels?

Louis Santillan
Haha...I'd be interested if you ever developed a 586 core at 1GHz that could utilize DDR-3 upto 4GB.


On Sat, May 4, 2013 at 1:43 AM, ht-lab <[hidden email]> wrote:
On 03/05/2013 15:55, Tom Ehlert wrote:

>> In the past, we compiled kernels for 8086, 186 and
>> 386 separately afair. I guess we got lazy and have
>> dropped 186 because very few users have 186/286 as
>> their CPU? They either have modern or REALLY old.
> this is not about 'lazy'
> it's easier for the user to select between 2 choices then between
> 4. multiply by 2 (FAT16/FAT32), this is 4 or 8 kernels.
>
> there's not much use for a 186 kernel as NOBODY has 186/286 machines
> these days,
Really, NOBODY.....

Hans
www.ht-lab.com




------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel