Hi!
30-Июн-2004 13:41 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
>>>> 0FA7 64 --free--
>>>> 0FAB 2.87k COMMAND
>>>> 1063 574k --free--
>>>> 9FEF 272 COMMAND environment
>> PS: I understand, that _currently_ you may wish not to bother with FreeCOM
>> code relocation (I think, if there are no UMBs, better if it will place its
>> new environment right before itself, over old environment segment), but
>> which _other_ contras you have against this?
SK> I have nothing against to place the environment somewhere else, in
SK> general; but it is _currently_ not possible to even consider to have
SK> environment right behind the process image. In order to ensure that, I
SK> will not touch the LAST_FIT setting. But offered you, or anybody how needs
SK> to squeeze the last byte, a way to relocate the environment.
SK> Actually, it would be even OK for an external program to move the
SK> environment to 0x1063,
I suggest, this may cause troubles for your swapping FreeCOM edition.
What I mean: FreeCOM loaded at FABh; when it runs program, it remains here
(shorter) stub and swaps itself somewhere. Let suggest, some program will
allocate memory at 1063h (right after stub). As I understand, this causes
troubles with swapping FreeCOM back (at over stub).
On ther other side, if there is possible to swap back at other place,
then who prevents FreeCOM from relocating its code to make space before it
for new environment (and, thus, also reuse space under old environment)? If
there are no UMBs?
SK> but to have FreeCOM do this - I have to change too many stuff that must
SK> be changed later on again, which would mean to waste my time usefully
SK> spent for other stuff.
Then write "more optimial, instead LAST_FIT, new environment
allocation" into your todos.
SK> BTW: I actually reworked to code to load the stub anywhere and, which in
SK> turn, loads the worker anywhere, too. Unfortunately I failed til today
SK> because of things the RTL relys on.
Yes, I know, PIC (Position Independent Code) is very non-trivial. :(
SK> That's why the current development branch and the "main" branch are way off.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
