At 12:30 AM 4/19/2004 +0200, Bernd Blaauw wrote:
>Michael,
>
>thanks for the newer release.
>I was surprised the /MAX: was in Kilobytes (expected Megabytes like /MAXMEM= has in 
>NT/2000/XP), but this way it does allow to finetune total memory, and thus for 
>instance, determine minimum amount of memory that our Graphical installer uses.

It could just as easily be megabytes.  It was written in K because XMS blocks are 
handled in kilobytes and saves about three lines of code to not convert the parameter 
during the check.  Cast your K/M vote with Tom before final release, or with me if you 
have a strong opinion and want it right away.  I'm neutral, either way it turns out to 
be released is fine with me.

>Don't know what happens when using a (too) low value..guess we'll have to find out.

It errors out, mirroring what would happen if there were insufficient extended memory 
for HIMEM to operate at startup, which is effectively what happens.

>Upper limit: 32bit limit would be 4GB I guess.

Yes.

>Default limit: 4GB?

Standard limit for extended memory is 4G.  HIMEM can't handle any more.  Nothing I 
know of supports the 64-bit extensions in protected mode, except very recent Windows 
version and probably a few new applications written for it.  Doubtful you'd ever see 
that support backported to DOS level.

>if specified limit is smaller than installed memory, remaining amount is discarded?
>or used as INT15 memory?

No, INT 15 isn't given it back as that would require more coding, and possibly not of 
any use were it to happen.  The memory is there and not really discarded.  Presumably 
if there were a driver or application which wanted to grab and claim the unused memory 
for its very own, the memory would be available.  It's like what happens to extended 
memory above 64M if you use /X and /NOABOVE16 to turn off the ability of HIMEM to use 
>64M memory; HIMEM simply doesn't see anything more.

>/METHOD: only a single value, or can user define a new searchorder?
>(throwing away all not-specified methods).
>default: /METHOD:ALWAYSON, BIOS, FAST, PS2, KBC, PORT92
>your behaviour: /METHOD:BIOS
>my suggestion: /METHOD:FAST,PORT92,BIOS  (does not even try ALWAYSON, PS2, KBC).

There is nothing illegal about specifying multiple methods such as  /METHOD:FAST 
/METHOD:KBC, but there isn't any use to do it.  /METHOD, like /MACHINE is a forced 
method to handle A20.  You can't force multiple A20 methods, it conceptually doesn't 
make sense for A20 to be handled more than one way.

What you want is an option which allows a user to subset the methods tested.  That 
would be possible in a separate option feature, but I'm not convinced there is a use 
for subsetting the method tests.  You either know what you want, or (typically) you 
want it to run the A20 tests to find out what you need.  Plus, HIMEM parsing routines 
would need to be reworked to handle variable parameters.

>does this mean XMSdsk works for Erwin on those 4GB machines?

He doesn't have daily access there, so debug cycles are pretty slow right now.  I 
don't know exactly where we are on that issue, it remains open.

>/MAX:xxxx    (xxxx in KiloBytes, probably upper value of 4096000 as that is all
>             that 32bit software can handle)

Upper value should be 4194303, which is (4G / 1024) - 1.  Not tested nearly that high.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to