Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Memory usage, AMIS(!) (Developers)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 13.05.2011, 14:51

> Thus using Japheth's bloat as an excuse to add Ciriaco's ?

Haven't you heard? Any amount of unnecessary bytes attracts more such.

> Back before 2000 I devised and used for myself a scheme for
> DOS programs to relocate themselves to the initial location of their own
> PSP and yes, their environment block [provided it was contiguous to the PSP
> which is not a given], by playing a few tricks documented and (s-c)
> undocumented, and going back to the system by int 21/4Ch not 31h, which was
> probably equivalent if not identical to what you promote.

Hmm, I don't know. My method will result in the least possible fragmentation (given the placement of other memory blocks), independent of where my PSP and environment were placed. I free the latter (of course) and move the former to my liking. (This is especially useful considering that well-meaning users might try "optimizing" the TSR's placement using LOADHIGH or other commands of that ilk, in effect possibly blocking the best UMB with the PSP and environment.) Of course I use Int21.4C for process termination too. (This obviously only applies to TSRs that do not need their PSP any more once they're resident. With TSRs that want to use their PSP again (- though a prior PSP relocation is still usually required for optimal placement -) using Int21.31 to terminate is just fine.)

I've recently thought of a different method were, instead of relocating the PSP using Int21.4C (hooking the entire parent, parent stack and PSP field in my PSP, Int22 and all)* one could terminate the process and then effectively place the TSR while using the original parent's process (hooking only Int22 and the parent stack field).** However, I don't think I'll implement that: I don't think it's advantageous in the general case; and it means one couldn't depend on any process resources during the final placement. (It might be advantageous in special cases with strict memory limits, like, say, an improved LOADFIX or UMB blocker that automatically unloads once a process launched by the program terminated.) (Such an incomplete termination hook strikes me as less portable and more dependent on DOS internals, too. Would have to look into it again to verify that though.)

* I guess because I terminate two times one could call my method "TTSR": "Terminate, Terminate again, and Stay Resident all the while".

** Analogous to TTSR, "TIJPSR": "Terminate Improperly then Jump to the Parent process, Staying Resident" ;-)

> Here's my suggestion to you - ONLY if you like it and can get that
> riches, TIME ! Since as I understand it you do have a working framework for
> optimal TSR relocation readied both in your mind and in your files, you
> might take KBFRINST.ASM (be sure to get the later version from my site),
> tear it to pieces and implement your scheme.

Yeah, I might do that later. Would have to look into porting the source code (as you might have heard I'm a fan of NASM too) or getting it to link properly somehow though. I'm not experienced enough with linkers to get them to output what I want them to output for my (T)TSR shenanigans though, so I would either have to learn something new or work around that.

> [only please DON'T touch any of the the "French" int 15/4F code
> proper, that plate of spaghetti only I can cook !

Alright. Given that neither I possess any French keyboard, nor have I really looked into keyboard layout mapping yet, I wouldn't want to change it anyhow.

> In retrospect, I should have written it from scratch, but
> initially did not think there would be so much to add to keybgr

But would you have come up with a better solution in the time that it took you to adapt Keybgr? I doubt it.

---
l

 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 197 users online (0 registered, 197 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum