[Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

2013-07-08 Thread Bertho Grandpied
Hi, Matej Horvat: 

 I've spent the last three hours writing a tiny COM program that moves
 COMMAND.COM's environment block to the lowest address possible (using
 DOS's low memory first fit strategy). 

Nice !

 Unfortunately, it does not seem to  
 be able to find the environment block if used in AUTOEXEC.BAT after 
 HIMEMX and JEMM386 were loaded in FDCONFIG.SYS (I only tested both at the 
 same  
 time, so I don't know which one causes the problem), 

My bet would be on JEMM as the one which messes with memory control blocks. 

 but it works if run  
 after AUTOEXEC.BAT has been processed (for some reason - but by then
 you may have TSRs loaded between COMMAND.COM and its environment,
 which may or may not be OK for your needs) or if those two drivers are not 
 loaded.

Yup. TSRs which are never unloaded would not be a problem, otherwise 
they could leave holes, but that's life... One could even re-run your 
program and try to relocate the ENV again into such a hole, if it's big
enough :=)

 So for example, without HIMEMX and JEMM386, FreeCOM will allocate its
 environment block at e. g. segment 9F7F, but after running the program,
 the environment block will reside at segment 23B4, almost immediately
after COMMAND.COM (it depends on the order in which you load TSRs).

Thanks. It would work indeed because - as I was checking a few minutes
before reading your mail - FreeCOM does maintain the master environment
pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
to use the contents of that 'slot', not some copy it made, whenever
it needs to access the ENV. At least a search (using debug!) did not
find the environment segment, as data, inside FreeCOM's live memory.

Of course it could be keeping the live ENV's segment in 
registers, but since that is C it's dubious registers are used for 
long time storage (contrary to what ASM code does profusely, at least mine).

Of course, I presume your program does care to adjust the PSP:3C pointer.

 Please contact me off-list if you want to try it out.

Well, thank you. A fully satisfactory solution ought to come from
FreeCOM's initialisation itself, though.

Regards

-- 
Czerno

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

2013-07-08 Thread Matej Horvat
 My bet would be on JEMM as the one which messes with memory control  
 blocks.

You're right. It is JEMM.

 Yup. TSRs which are never unloaded would not be a problem, otherwise
 they could leave holes, but that's life... One could even re-run your
 program and try to relocate the ENV again into such a hole, if it's big
 enough :=)

Sure, you can run it any number of times.

 FreeCOM does maintain the master environment
 pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
 to use the contents of that 'slot', not some copy it made, whenever
 it needs to access the ENV.

3Ch is reserved as far as I know. Do you mean 2Ch? That's what my program  
modifies.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Re : Freedos-user Digest, Vol 808, Issue 1

2013-07-08 Thread Tom Ehlert
 Thanks. It would work indeed because - as I was checking a few minutes
 before reading your mail - FreeCOM does maintain the master environment
 pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
 to use the contents of that 'slot', not some copy it made, whenever
 it needs to access the ENV.

that's how 'edit the parent/master environment' utilities work(ed),
it's 'documented undocumented' behaviour, and FreeCOM behaves and has
to behave) the same way.
 At least a search (using debug!) did not
 find the environment segment, as data, inside FreeCOM's live memory.

 Of course it could be keeping the live ENV's segment in 
 registers, but since that is C it's dubious registers are used for 
 long time storage (contrary to what ASM code does profusely, at least mine).

if the master environment would be simply
'data' with some internal variable pointing to it, the master
environment would be obviously swapped out (or located at :)

but of course you knew that

tom


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user