Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Borlands TLINK and minimizing an EXEs memory usage
29 views
Skip to first unread message
R.Wieser
Apr 3, 2013, 4:46:14 PM4/3/13
to
Hello all,
I just created an EXE style executable, in which I tried to allocate 32
KByte of memory using INT 21h, AH=48h. To my amazement it failed, and
reported I could just get 7 segments worth of it. I always thought that an
EXE style program used as much as it needed, and no more :-\
Some googeling later I was reaquainted with the min- and max-allocation
(WORDs at PSP:000Ah and PSP:000Ch), and how that last one would often be
defaulted to 0FFFFh, meaning all memory would be assigned to the executable.
That same googeling told me that I should be able to tell my linker program
to change that last value to something more sensible.
Now the problem: I'm using Borlands TLINK v7.1 , and can't seem to find the
switch I would need to use. So, any of you (old hands) know ? I would
sure want to hear about it (it would beat both adding INT 21h, AH=4Ah code
or editing that value in the resulting executable).
Regards,
Rudy Wieser
I just created an EXE style executable, in which I tried to allocate 32
KByte of memory using INT 21h, AH=48h. To my amazement it failed, and
reported I could just get 7 segments worth of it. I always thought that an
EXE style program used as much as it needed, and no more :-\
Some googeling later I was reaquainted with the min- and max-allocation
(WORDs at PSP:000Ah and PSP:000Ch), and how that last one would often be
defaulted to 0FFFFh, meaning all memory would be assigned to the executable.
That same googeling told me that I should be able to tell my linker program
to change that last value to something more sensible.
Now the problem: I'm using Borlands TLINK v7.1 , and can't seem to find the
switch I would need to use. So, any of you (old hands) know ? I would
sure want to hear about it (it would beat both adding INT 21h, AH=4Ah code
or editing that value in the resulting executable).
Regards,
Rudy Wieser
Steve
Apr 4, 2013, 8:51:38 AM4/4/13
to
"R.Wieser" <add...@not.available> writes:
>Hello all,
>
>I just created an EXE style executable, in which I tried to allocate 32
>KByte of memory using INT 21h, AH=48h. To my amazement it failed, and
>reported I could just get 7 segments worth of it. I always thought that an
>EXE style program used as much as it needed, and no more :-\
>
>Some googeling later I was reaquainted with the min- and max-allocation
>(WORDs at PSP:000Ah and PSP:000Ch), and how that last one would often be
>defaulted to 0FFFFh, meaning all memory would be assigned to the executable.
WORDs in the header of the executable file, not the PSP.
>Hello all,
>
>I just created an EXE style executable, in which I tried to allocate 32
>KByte of memory using INT 21h, AH=48h. To my amazement it failed, and
>reported I could just get 7 segments worth of it. I always thought that an
>EXE style program used as much as it needed, and no more :-\
>
>Some googeling later I was reaquainted with the min- and max-allocation
>(WORDs at PSP:000Ah and PSP:000Ch), and how that last one would often be
>defaulted to 0FFFFh, meaning all memory would be assigned to the executable.
>
>That same googeling told me that I should be able to tell my linker program
>to change that last value to something more sensible.
>
>Now the problem: I'm using Borlands TLINK v7.1 , and can't seem to find the
>switch I would need to use. So, any of you (old hands) know ? I would
>sure want to hear about it (it would beat both adding INT 21h, AH=4Ah code
>or editing that value in the resulting executable).
like that is documented. So maybe Borland never implemented
it. For the 16-bit Microsoft linker the switch is /CP or
/CPARMAXALLOC. Sorry if this is unhelpful.
Why not check the PSP and use the second word (pspNextParagraph
in MS speak) to see if enough memory was allocated and just
use it? That seems easier than deallocaing memory just to
reallocate it.
Regards,
Steve N.
R.Wieser
Apr 4, 2013, 11:51:07 AM4/4/13
to
Hello Steve,
> WORDs in the header of the executable file, not the PSP.
I'm sorry, you're right. I've not done 16-bit coding for a while.
> I have some documentation for TASM/TLINK V2.0, and
> nothing like that is documented. So maybe Borland never
> implemented it.
Nothing like it is mentioned in the ducumentation of the linker I mentioned
either, nor does the help of TLink v1.01 show anything like it.
Its quite possible that you're right, but had/have to make sure.
> Why not check the PSP and use the second word
> (pspNextParagraph in MS speak) to see if enough memory
> was allocated and just use it? That seems easier than
> deallocaing memory just to reallocate it.
Well, for two simple reasons actually: 1) it bugged me that I could not use
the allocation call. 2) to me its untidy housekeeping to just let programs
do whatever they please.
And I could think of a situation where allocation and deallocation is done
dynamically, done as a response of external events. For just a situation I
would like to be burdened with the knowledge how to do it correctly. :-)
As for your remark ? Yes, I also got that idea and will probably implement
it, but most likely not without releasing the unneeded memory back to the
OS.
Thanks for the help,
Rudy Wieser
-- Origional message:
Steve <Bo...@Embarq.com> schreef in berichtnieuws
c1.2b8.3ZhPDW$0...@NOVOSAD3.EMBARQ.COM...
> WORDs in the header of the executable file, not the PSP.
> I have some documentation for TASM/TLINK V2.0, and
> nothing like that is documented. So maybe Borland never
> implemented it.
either, nor does the help of TLink v1.01 show anything like it.
Its quite possible that you're right, but had/have to make sure.
> Why not check the PSP and use the second word
> (pspNextParagraph in MS speak) to see if enough memory
> was allocated and just use it? That seems easier than
> deallocaing memory just to reallocate it.
the allocation call. 2) to me its untidy housekeeping to just let programs
do whatever they please.
And I could think of a situation where allocation and deallocation is done
dynamically, done as a response of external events. For just a situation I
would like to be burdened with the knowledge how to do it correctly. :-)
As for your remark ? Yes, I also got that idea and will probably implement
it, but most likely not without releasing the unneeded memory back to the
OS.
Thanks for the help,
Rudy Wieser
-- Origional message:
Steve <Bo...@Embarq.com> schreef in berichtnieuws
c1.2b8.3ZhPDW$0...@NOVOSAD3.EMBARQ.COM...
Ross Ridge
Apr 4, 2013, 4:40:13 PM4/4/13
to
R.Wieser <add...@not.available> wrote:
>Well, for two simple reasons actually: 1) it bugged me that I could not use
>the allocation call. 2) to me its untidy housekeeping to just let programs
>do whatever they please.
This is MS-DOS. Programs can do whatever they please.
>Well, for two simple reasons actually: 1) it bugged me that I could not use
>the allocation call. 2) to me its untidy housekeeping to just let programs
>do whatever they please.
The correct way to handle this is let the EXE allocate all of memory
at startup and then resize this allocation to what you actually need.
This way you can use an "end" label in your code to mark exactly where
your program's initial allocation really ends. Otherwise you're just
putting some value in to the EXE header that you're going to need to
adjust everytime you make a change to your program.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
R.Wieser
Apr 4, 2013, 6:43:38 PM4/4/13
to
Hello Ross,
> This is MS-DOS. Programs can do whatever they please.
Not on my watch they don't. Either they behave or they get thrown back into
the idea-soup they came from. :-)
> The correct way to handle this is let the EXE allocate all of
> memory at startup and then resize this allocation to what you
> actually need.
I disagree. The *correct* way is to have the .EXE header mention how much
your program needs, and let exactly that ammount be allocated for it by the
OS.
But if thats the thing than I will just ditch the whole .EXE style (again),
and revert even further back to .COM. It does just that (grabbing all
memory) by default, and it does not carry the relocation data with it .EXE
does, thus shaving 256 bytes+ from the filesize (which was quite important
in the time when floppies where dominant ...).
> This way you can use an "end" label in your code to mark exactly
> where your program's initial allocation really ends.
While taking care to include the initialized and uninitialized data
ofcourse. Yeah, that is what I always did when I wrote .COM style programs.
Actually, if you do not mind wasting between 1 and 15 bytes than the WORD at
offset DS:000Ah (minalloc) in a .EXE will give you exactly that.
> Otherwise you're just putting some value in to the EXE
> header that you're going to need to adjust everytime you
> make a change to your program.
Just like I need to convert the sourcecode to an .EXE every time ? :-)
But its looks quite straight-forward: after having link done its job just
let another (very small) program copy the WORD from offset 000Ah to 000Ch
(making maxalloc equal to minalloc) and the job is done.
Regards,
kjkofd$c11$1...@rumours.uwaterloo.ca...
> This is MS-DOS. Programs can do whatever they please.
the idea-soup they came from. :-)
> The correct way to handle this is let the EXE allocate all of
> memory at startup and then resize this allocation to what you
> actually need.
your program needs, and let exactly that ammount be allocated for it by the
OS.
But if thats the thing than I will just ditch the whole .EXE style (again),
and revert even further back to .COM. It does just that (grabbing all
memory) by default, and it does not carry the relocation data with it .EXE
does, thus shaving 256 bytes+ from the filesize (which was quite important
in the time when floppies where dominant ...).
> This way you can use an "end" label in your code to mark exactly
> where your program's initial allocation really ends.
ofcourse. Yeah, that is what I always did when I wrote .COM style programs.
Actually, if you do not mind wasting between 1 and 15 bytes than the WORD at
offset DS:000Ah (minalloc) in a .EXE will give you exactly that.
> Otherwise you're just putting some value in to the EXE
> header that you're going to need to adjust everytime you
> make a change to your program.
But its looks quite straight-forward: after having link done its job just
let another (very small) program copy the WORD from offset 000Ah to 000Ch
(making maxalloc equal to minalloc) and the job is done.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
-- Origional message:
kjkofd$c11$1...@rumours.uwaterloo.ca...
Ross Ridge
Apr 4, 2013, 7:51:42 PM4/4/13
to
Ross Ridge writes:
> The correct way to handle this is let the EXE allocate all of
> memory at startup and then resize this allocation to what you
> actually need.
> The correct way to handle this is let the EXE allocate all of
> memory at startup and then resize this allocation to what you
> actually need.
R.Wieser <add...@not.available> wrote:
>I disagree. The *correct* way is to have the .EXE header mention how much
>your program needs, and let exactly that ammount be allocated for it by the
>OS.
Standard practice is to resize the initial allocation. You haven't
>I disagree. The *correct* way is to have the .EXE header mention how much
>your program needs, and let exactly that ammount be allocated for it by the
>OS.
suddenly discovered some better way of doing things, you're just repeating
old mistakes.
>> Otherwise you're just putting some value in to the EXE
>> header that you're going to need to adjust everytime you
>> make a change to your program.
>
>Just like I need to convert the sourcecode to an .EXE every time ? :-)
new program to calculate for you. You might as well add the small bit
of code to your EXE and do it properly. Then it becomes no different
than how your source code is converted to an EXE, because it is part of
your source code that's converted to an EXE.
>But its looks quite straight-forward: after having link done its job just
>let another (very small) program copy the WORD from offset 000Ah to 000Ch
>(making maxalloc equal to minalloc) and the job is done.
the correct value. Resizing the initial allocation is also how you ensure
that the actual minimal amount of memory your program needs is available.
R.Wieser
Apr 5, 2013, 5:50:01 AM4/5/13
to
Hello Ross,
> Standard practice is to resize the initial allocation
The standard way is to let the specs embedded in the executable handle it.
> You haven't suddenly discovered some better way of doing things,
Huh ? I was not out for, nor did I try to suggest any such thing. The
only thing I *did* say was that if a certain mechanism is available to solve
certain problems it should be used.
> you're just repeating old mistakes.
You mean that wanting to know why a perfectly good method *isn't* used is
"repeating old mistakes", but consistently hacking around it isn't ?
Really ? :-\ :-)
> No. It's something you need to either calculate manually or
> write a new program to calculate for you. You might as well
> add the small bit of code to your EXE and do it properly.
Huh ? My apologies, but you suggesting me to consistently use a
hack/work-around and than call it "do it properly" is a bit much for me.
> You're assuming that the minalloc value that the linker comes up
> with is the correct value.
Yep. That is, as long as you specified enough (uninitialized) data.
> Resizing the initial allocation is also how you ensure that the
> actual minimal amount of memory your program needs is available.
Nope. Or yep but still nope.
The 'minalloc' value is there to make sure that your program will be loaded
in a memoryblock that can hold it. There is no further need for resizing
when it fits. Assuming ofcourse you requested the "extra" memory <quote>the
correct way</quote> by asking for some uninitialized data in your program.
Your method ? Depending on the allocation-strategy of the OS and/or memory
fragmentation your program could be placed in a small memoryblock, with very
little room beyond it. Your "resizing" -- which ammounts to shrinking
actually -- would return a failure as there just isn't enough continous
space for you. Even though there *could* be another memory-block available
that would satisfy your extra needs ...
In other words: You seem to be *creating* problems by bad
programming-habits, only than to suggest downright hacks -- <quote>repeating
old mistakes</quote> -- to "solve" the result of them. :-\
> You're assuming that the minalloc value that the linker comes
> up with is the correct value.
Jup. Just like you seem to be assuming that the value you conjure up for
the "resizing" is the right one. Guess which of those two I give more
credit to ? <whistle>
But feel free to come up with a situation/situations where it goes wrong.
Seriously, I would like to know, as in that case I can than learn from it
and maybe avoid such pitfalls in the future.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
kjl3me$66o$1...@rumours.uwaterloo.ca...
> Standard practice is to resize the initial allocation
> You haven't suddenly discovered some better way of doing things,
only thing I *did* say was that if a certain mechanism is available to solve
certain problems it should be used.
> you're just repeating old mistakes.
"repeating old mistakes", but consistently hacking around it isn't ?
Really ? :-\ :-)
> No. It's something you need to either calculate manually or
> write a new program to calculate for you. You might as well
> add the small bit of code to your EXE and do it properly.
hack/work-around and than call it "do it properly" is a bit much for me.
> You're assuming that the minalloc value that the linker comes up
> with is the correct value.
> Resizing the initial allocation is also how you ensure that the
> actual minimal amount of memory your program needs is available.
The 'minalloc' value is there to make sure that your program will be loaded
in a memoryblock that can hold it. There is no further need for resizing
when it fits. Assuming ofcourse you requested the "extra" memory <quote>the
correct way</quote> by asking for some uninitialized data in your program.
Your method ? Depending on the allocation-strategy of the OS and/or memory
fragmentation your program could be placed in a small memoryblock, with very
little room beyond it. Your "resizing" -- which ammounts to shrinking
actually -- would return a failure as there just isn't enough continous
space for you. Even though there *could* be another memory-block available
that would satisfy your extra needs ...
In other words: You seem to be *creating* problems by bad
programming-habits, only than to suggest downright hacks -- <quote>repeating
old mistakes</quote> -- to "solve" the result of them. :-\
> You're assuming that the minalloc value that the linker comes
> up with is the correct value.
the "resizing" is the right one. Guess which of those two I give more
credit to ? <whistle>
But feel free to come up with a situation/situations where it goes wrong.
Seriously, I would like to know, as in that case I can than learn from it
and maybe avoid such pitfalls in the future.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
Steve
Apr 5, 2013, 8:21:03 AM4/5/13
to
"R.Wieser" <add...@not.available> writes:
>Hello Ross,
>
>> Standard practice is to resize the initial allocation
>
>The standard way is to let the specs embedded in the executable handle it.
>
>> You haven't suddenly discovered some better way of doing things,
>
>Huh ? I was not out for, nor did I try to suggest any such thing. The
>only thing I *did* say was that if a certain mechanism is available to solve
>certain problems it should be used.
>
>> you're just repeating old mistakes.
>
>You mean that wanting to know why a perfectly good method *isn't* used is
>"repeating old mistakes", but consistently hacking around it isn't ?
>Really ? :-\ :-)
Hi Rudy,
>Hello Ross,
>
>> Standard practice is to resize the initial allocation
>
>The standard way is to let the specs embedded in the executable handle it.
>
>> You haven't suddenly discovered some better way of doing things,
>
>Huh ? I was not out for, nor did I try to suggest any such thing. The
>only thing I *did* say was that if a certain mechanism is available to solve
>certain problems it should be used.
>
>> you're just repeating old mistakes.
>
>You mean that wanting to know why a perfectly good method *isn't* used is
>"repeating old mistakes", but consistently hacking around it isn't ?
>Really ? :-\ :-)
FTR, I have seen very few programs actually use the exMaxAlloc
method to limit the memory usage. I tried it, with mixed results.
Don't use it in combination with /EXEPACK with MS's LINK. But
otherwise it seems to work well. I saw it used in one case where
it was used so the programmer could allocate a fixed amount of
memory, which I consider counter-productive. Just declaring the
memory required in a data segment is easier. But I do feel if you
want to limit the memory footprint, then the EXEHEADER
exMaxAlloc is the way to go. YMMV.
Regards,
Steve N.
R.Wieser
Apr 5, 2013, 10:02:44 AM4/5/13
to
Hello Steve,
> Don't use it in combination with /EXEPACK with MS's LINK.
> But otherwise it seems to work well.
Thanks. As I'm using Borlands TLINK I think that I'm than in the safe zone.
:-)
> I saw it used in one case where it was used so the programmer
> could allocate a fixed amount of memory, which I consider
> counter-productive.
Well, you can't really rely on getting that extra memory anyway.
Its just that its possible that you will get it *if* there is a block of
memory available thats large enough to accomodate that extra size. If not
... well, your program gets loaded as long as the minimum size is satisfied
(and you need to include some checking for that situation).
>Just declaring the memory required in a data segment is easier.
As in defining some uninitialized data ? Yes, that would be better, as well
as easier -- at least that way you can be certain that, when the executable
is started, the memory is actually available to it.
> But I do feel if you want to limit the memory footprint, then
> the EXEHEADER exMaxAlloc is the way to go.
I thought so too, but as you might have noticed, not all of us here do. :-)
To be honest, I don't think that there will be many situations where loading
a one-block program (code and all needed data) will fail (even if its done
by trying to just grab memory over the ammount that is specified in
minAlloc) where a two-block (code with static data, more allocated later)
will succeede. Especially when you consider that programs are by default
loaded in the largest available free memory block.
Thanks for the response.
regards,
> Don't use it in combination with /EXEPACK with MS's LINK.
> But otherwise it seems to work well.
:-)
> I saw it used in one case where it was used so the programmer
> could allocate a fixed amount of memory, which I consider
> counter-productive.
Its just that its possible that you will get it *if* there is a block of
memory available thats large enough to accomodate that extra size. If not
... well, your program gets loaded as long as the minimum size is satisfied
(and you need to include some checking for that situation).
>Just declaring the memory required in a data segment is easier.
as easier -- at least that way you can be certain that, when the executable
is started, the memory is actually available to it.
> But I do feel if you want to limit the memory footprint, then
> the EXEHEADER exMaxAlloc is the way to go.
To be honest, I don't think that there will be many situations where loading
a one-block program (code and all needed data) will fail (even if its done
by trying to just grab memory over the ammount that is specified in
minAlloc) where a two-block (code with static data, more allocated later)
will succeede. Especially when you consider that programs are by default
loaded in the largest available free memory block.
Thanks for the response.
regards,
Rudy Wieser
-- Origional message:
-- Origional message:
Steve <Bo...@Embarq.com> schreef in berichtnieuws
c1.2b8.3Zj0Vl$0...@NOVOSAD3.EMBARQ.COM...
Ross Ridge
Apr 5, 2013, 8:56:53 PM4/5/13
to
Ross Ridge writes:
> Standard practice is to resize the initial allocation
> Standard practice is to resize the initial allocation
R.Wieser <add...@not.available> wrote:
> The standard way is to let the specs embedded in the executable
> handle it.
No, if that were the case you wouldn't have to jump through hoops to
> The standard way is to let the specs embedded in the executable
> handle it.
implement it. Your linker would just set the value "correctly".
If you want to tilt at windmills no one is going to stop you. But you're
fooling no one other than yourself by arguing what you're trying to do is
"standard" or "correct".
R.Wieser
Apr 6, 2013, 6:37:51 AM4/6/13
to
Ross,
> No, if that were the case you wouldn't have to jump through hoops to
> implement it. Your linker would just set the value "correctly".
Depending on what you call "correctly" of course (thanks for the quotes on
that).
But yes, that Borland has forgotten to give me an option to set that value
is a flaw of *Borland*, not the spects to the EXE format.
Also remember that other linkers *do* seem to have the option to change it
to whatever you like.
In short: your argument is blown outof the water.
> If you want to tilt at windmills no one is going to stop you.
> But you're fooling no one other than yourself by arguing
> what you're trying to do is "standard" or "correct".
If you want to stay willfully blind, including ignoring all the signals that
the problem I have with my linker is not at all universal and you want to
keep on going "suggesting" bad programming practices (adding bandaids where
solutions would be more apropriate -- in my case I'm thinking of replacing
my linker) you're very welcome. Just don't expect from me to applaud you
for it.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
kjnrsl$hct$1...@rumours.uwaterloo.ca...
> No, if that were the case you wouldn't have to jump through hoops to
> implement it. Your linker would just set the value "correctly".
that).
But yes, that Borland has forgotten to give me an option to set that value
is a flaw of *Borland*, not the spects to the EXE format.
Also remember that other linkers *do* seem to have the option to change it
to whatever you like.
In short: your argument is blown outof the water.
> If you want to tilt at windmills no one is going to stop you.
> But you're fooling no one other than yourself by arguing
> what you're trying to do is "standard" or "correct".
the problem I have with my linker is not at all universal and you want to
keep on going "suggesting" bad programming practices (adding bandaids where
solutions would be more apropriate -- in my case I'm thinking of replacing
my linker) you're very welcome. Just don't expect from me to applaud you
for it.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
JJ
Apr 6, 2013, 10:10:50 AM4/6/13
to
On Sat, 6 Apr 2013 12:37:51 +0200, R.Wieser wrote:
> Also remember that other linkers *do* seem to have the option to change it
> to whatever you like.
But it's hard to find one that support OMF.
> Also remember that other linkers *do* seem to have the option to change it
> to whatever you like.
What's the linker tool that's part of GCC?
Maybe that can be used to replace TLINK?
R.Wieser
Apr 6, 2013, 1:38:19 PM4/6/13
to
Hello JJ,
> But it's hard to find one that support OMF.
> What's the linker tool that's part of GCC?
> Maybe that can be used to replace TLINK?
I'm looking, I'm looking :-)
Hey, if all else fails I still have at least two work-arounds open:
grabbing the minAlloc value and resize the used memory with that or even the
way Ross advocates (which normally is only done with .COM files), or create
a small program to, just after the exe is generated, copy the 'minAlloc' to
the 'maxAlloc' value.
Heck, I might even try to patch my linker to store the minAlloc value in
both places. :-)
Regards,
Rudy Wieser
-- Origional message:
JJ <jaej...@nah.meh> schreef in berichtnieuws
1r9dxu7ofr8qg$.nfbyvb184hbv.dlg@40tude.net...
> But it's hard to find one that support OMF.
> What's the linker tool that's part of GCC?
> Maybe that can be used to replace TLINK?
Hey, if all else fails I still have at least two work-arounds open:
grabbing the minAlloc value and resize the used memory with that or even the
way Ross advocates (which normally is only done with .COM files), or create
a small program to, just after the exe is generated, copy the 'minAlloc' to
the 'maxAlloc' value.
Heck, I might even try to patch my linker to store the minAlloc value in
both places. :-)
Regards,
Rudy Wieser
-- Origional message:
1r9dxu7ofr8qg$.nfbyvb184hbv.dlg@40tude.net...
Ross Ridge
Apr 7, 2013, 2:34:58 AM4/7/13
to
Ross Ridge writes:
> No, if that were the case you wouldn't have to jump through hoops to
> implement it. Your linker would just set the value "correctly".
> No, if that were the case you wouldn't have to jump through hoops to
> implement it. Your linker would just set the value "correctly".
R.Wieser <add...@not.available> wrote:
>But yes, that Borland has forgotten to give me an option to set that value
>is a flaw of *Borland*, not the spects to the EXE format.
The Borland linker was written by professional programmers who jobs
>But yes, that Borland has forgotten to give me an option to set that value
>is a flaw of *Borland*, not the spects to the EXE format.
depended on getting things like this correct. Those people, who had
infinitely more knowledge and experience than you, decided that you
didn't need this option.
>If you want to stay willfully blind, including ignoring all the signals that
>the problem I have with my linker is not at all universal and you want to
>keep on going "suggesting" bad programming practices (adding bandaids where
>solutions would be more apropriate -- in my case I'm thinking of replacing
>my linker) you're very welcome. Just don't expect from me to applaud you
>for it.
example of vast majority of MS-DOS programmers who never set this
header value, letting their EXEs allocate all of memory a startup.
I'm not who's saying what all these people, all these experienced and
professional programmers, were doing was a bad programming practice.
I'm not the one who's so arrogant and delusional that he believes that
he's correct and all these programmers must have been wrong
R.Wieser
Apr 7, 2013, 1:55:47 PM4/7/13
to
Ross,
> > No, if that were the case you wouldn't have to jump through hoops to
> > implement it.
My apologies, but what didn't you understand from the below ?
<quote>But yes, that Borland has forgotten to give me an option to set that
value is a flaw of *Borland*, not the spects to the EXE format</quote>
> Your linker would just set the value "correctly".
Ah, you mean that there is just a single correct setting for such a thing ?
If there is, why did they include it in every programs header and not simply
in the loader ? I guess that did not enter your thoughts yet. :-)
> The Borland linker was written by professional programmers
> who jobs depended on getting things like this correct.
Lolz. You do know that Borland does not exist anymore ? Here I could say
they failed at doing their jobs right and thus subsequently lost them and
leave it at that.
But I do not need to: I've got examples here (I stumbled over myself) which
which will cause Borlands product exhibit a range of incorrect behaviour,
from simply crashing to silently creating faulty executables to throwing
garbage on the screen to silently ignore parts of commands. Said
otherwise, I have hard evidence here that they made mistakes. Big ones.
But I do not know if them being 'professional programmers' is even relevant
here. Not including the option could have been a simple management
decision.
Apart from that, companies like MS and other big ones seemingly continuously
push updates of their software, which are mostly bugfixes. That alone
should tell you that those "professional programmers" are definitily not
flawless.
> Those people, who had infinitely more knowledge and experience
> than you, decided that you didn't need this option.
Well, it looks like they where wrong. I *do* need that option. You can
argue as much as you like, but thats the fact.
> I'm not the one ignoring the example of vast majority of
> MS-DOS programmers who never set this header value
Be honest: You could, at this moment, not name five people you have actually
asked for their opinion on this.
At this point you are not arguing the merrit of your claims anymore, you're
simply trying to bluff me. Sorry, doesn't work.
> I'm not who's saying what all these people, all these experienced
> and professional programmers, were doing was a bad programming
> practice.
No, but you are (again) trying to insinuate that "all these experienced and
professional programmers" are doing the exact same as you (possible, but not
likely), and that the reason for that is the same as yours (not at all
likely). Cheap parlor tricks I'm afraid. You have *no clue* if either is
true, and probably never will even try as much as to ask any of those
'professional programmers'.
I however *did* say that *you* are exhibiting bad programming habits. Which
you now fervently defend. Without really having arguments.
> I'm not the one who's so arrogant and delusional that he
> believes that he's correct and all these programmers must
> have been wrong
Apart from the "all those people (you know absolutily nothing about)" claim
? Lolz. I'm not the one who is "so arrogant and delusional" to think that
his method is *the only good* one.
You know, In the past I have been using the method you're advocating. For
.COM files that is, not for .EXE style ones. That means that (I agree that)
your specific method does have merrit. Just not for what you use it for.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
kjr42i$vv2$1...@rumours.uwaterloo.ca...
> > No, if that were the case you wouldn't have to jump through hoops to
> > implement it.
<quote>But yes, that Borland has forgotten to give me an option to set that
value is a flaw of *Borland*, not the spects to the EXE format</quote>
> Your linker would just set the value "correctly".
If there is, why did they include it in every programs header and not simply
in the loader ? I guess that did not enter your thoughts yet. :-)
> The Borland linker was written by professional programmers
> who jobs depended on getting things like this correct.
they failed at doing their jobs right and thus subsequently lost them and
leave it at that.
But I do not need to: I've got examples here (I stumbled over myself) which
which will cause Borlands product exhibit a range of incorrect behaviour,
from simply crashing to silently creating faulty executables to throwing
garbage on the screen to silently ignore parts of commands. Said
otherwise, I have hard evidence here that they made mistakes. Big ones.
But I do not know if them being 'professional programmers' is even relevant
here. Not including the option could have been a simple management
decision.
Apart from that, companies like MS and other big ones seemingly continuously
push updates of their software, which are mostly bugfixes. That alone
should tell you that those "professional programmers" are definitily not
flawless.
> Those people, who had infinitely more knowledge and experience
> than you, decided that you didn't need this option.
argue as much as you like, but thats the fact.
> I'm not the one ignoring the example of vast majority of
> MS-DOS programmers who never set this header value
asked for their opinion on this.
At this point you are not arguing the merrit of your claims anymore, you're
simply trying to bluff me. Sorry, doesn't work.
> I'm not who's saying what all these people, all these experienced
> and professional programmers, were doing was a bad programming
> practice.
professional programmers" are doing the exact same as you (possible, but not
likely), and that the reason for that is the same as yours (not at all
likely). Cheap parlor tricks I'm afraid. You have *no clue* if either is
true, and probably never will even try as much as to ask any of those
'professional programmers'.
I however *did* say that *you* are exhibiting bad programming habits. Which
you now fervently defend. Without really having arguments.
> I'm not the one who's so arrogant and delusional that he
> believes that he's correct and all these programmers must
> have been wrong
? Lolz. I'm not the one who is "so arrogant and delusional" to think that
his method is *the only good* one.
You know, In the past I have been using the method you're advocating. For
.COM files that is, not for .EXE style ones. That means that (I agree that)
your specific method does have merrit. Just not for what you use it for.
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
Ross Ridge
Apr 7, 2013, 4:07:42 PM4/7/13
to
Ross Ridge writes:
> I'm not the one ignoring the example of vast majority of
> MS-DOS programmers who never set this header value
> I'm not the one ignoring the example of vast majority of
> MS-DOS programmers who never set this header value
R.Wieser <add...@not.available> wrote:
>Be honest: You could, at this moment, not name five people you have actually
>asked for their opinion on this.
Steve N already confirmed the fact that most programmers don't set this
>Be honest: You could, at this moment, not name five people you have actually
>asked for their opinion on this.
header value. That's one person you should've known about already,
if you weren't being so willfully blind. I can also point to the vast
majority of the MS-DOS excutables sitting on my machine, from Microsoft's
own MS-DOS commands, to countless games and utlities. Countless EXEs all
configured to allocate the maximum amount of memory at startup. That adds
up to far more than five MS-DOS programmers, all more experienced and
knowledgable than you, that choose to never set this header value.
All you have to support your claim that this is bad practice is the
unsupported assertions of one lone novice programmer: yourself.
R.Wieser
Apr 7, 2013, 6:32:15 PM4/7/13
to
Ross,
> Steve N already confirmed the fact that most programmers
> don't set this header value.
He did ? Where ? Not in the two messages he posted in this thread. But
feel free to quote it (It won't be easy to get what the actually said to
mean what you think/want it to mean though).
> I can also point to the vast majority of the MS-DOS excutables
> sitting on my machine, from Microsoft's own MS-DOS commands,
> to countless games and utlities. Countless EXEs all configured to
> allocate the maximum amount of memory at startup.
Could be true. If it is the first thing I would do would be wondering why
they did it, and why they kept doing it that way. You do not seem to have
any such thoughts. Why ?
But thats not really the question here. What is is your persistance to use
extra code with using a manually defined size over methods which are already
build in. Again, why ?
> All you have to support your claim that this is bad practice
> is the unsupported assertions of one lone novice programmer:
> yourself.
You know that I'm a novice, based on what exactly ? Let me guess, because I
do not agree with your stance ... :-)
And am I now supposed to counter that by devulging some of my past venues,
after which you than will simply state that I'm still a novice of
....whatever ? Nahhh... Lets not do that.
But feel free to ask your teacher. Math or programming, it does not matter.
Both will tell you that simpler is better. Not having/adding code which
can already be done by other means *is* simpler.
I would have liked to say that if the correct tool is not available your
method could be good, but as you said you are calculating the size yourself
(and do not take the available minAlloc value) I would be lying.
Oh, by the way: If that minAlloc value isn't always right its another
example of how those "professional programmers" you spoke of in your
previous message make mistakes.
But I have to conceede to a thing though: if I want to share my sourcecode
with others I need to keep in mind that those others could have flawed
tools. And that means that although I could correct the situation for
myself I would probably need to add some code to shink the apps memory, so
others can create an executable from it without needing to add code
themselves.
It could also be why the solution you are using has survived for so long ...
Than again, I could add something like a "NoMaxAlloc" definition somewhere,
and let the "shrink me" code be included depending on its setting.
Hey Ross, did you notice ? In just a few lines I've named the pros and
contras of a few methods, and am trying to make my decision based on those.
I've been told its a quite scientific method, and the way to go. :-)
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
kjsjme$e5l$1...@rumours.uwaterloo.ca...
> Steve N already confirmed the fact that most programmers
> don't set this header value.
feel free to quote it (It won't be easy to get what the actually said to
mean what you think/want it to mean though).
> I can also point to the vast majority of the MS-DOS excutables
> sitting on my machine, from Microsoft's own MS-DOS commands,
> to countless games and utlities. Countless EXEs all configured to
> allocate the maximum amount of memory at startup.
they did it, and why they kept doing it that way. You do not seem to have
any such thoughts. Why ?
But thats not really the question here. What is is your persistance to use
extra code with using a manually defined size over methods which are already
build in. Again, why ?
> All you have to support your claim that this is bad practice
> is the unsupported assertions of one lone novice programmer:
> yourself.
do not agree with your stance ... :-)
And am I now supposed to counter that by devulging some of my past venues,
after which you than will simply state that I'm still a novice of
....whatever ? Nahhh... Lets not do that.
But feel free to ask your teacher. Math or programming, it does not matter.
Both will tell you that simpler is better. Not having/adding code which
can already be done by other means *is* simpler.
I would have liked to say that if the correct tool is not available your
method could be good, but as you said you are calculating the size yourself
(and do not take the available minAlloc value) I would be lying.
Oh, by the way: If that minAlloc value isn't always right its another
example of how those "professional programmers" you spoke of in your
previous message make mistakes.
But I have to conceede to a thing though: if I want to share my sourcecode
with others I need to keep in mind that those others could have flawed
tools. And that means that although I could correct the situation for
myself I would probably need to add some code to shink the apps memory, so
others can create an executable from it without needing to add code
themselves.
It could also be why the solution you are using has survived for so long ...
Than again, I could add something like a "NoMaxAlloc" definition somewhere,
and let the "shrink me" code be included depending on its setting.
Hey Ross, did you notice ? In just a few lines I've named the pros and
contras of a few methods, and am trying to make my decision based on those.
I've been told its a quite scientific method, and the way to go. :-)
Regards,
Rudy Wieser
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
Rod Pemberton
Apr 7, 2013, 8:20:41 PM4/7/13
to
"R.Wieser" <add...@not.available> wrote in message
news:515c94db$0$6871$e4fe...@news2.news.xs4all.nl...
Well, I'm not an old hand with TLINK. So, I hoped someone else
could provide an appropriate answer.
However, I do have a half dozen different versions of TLINK
around. These were all scrounged from the dark corners of the
Internet... I almost never use TLINK. I have it just in case I
need to compile some code using it. So, TLINK's built-in help
page is about all I know about it's options. That's displayed
when executed without arguments. The oldest (2.0) and newest
(7.1.30.1) versions do not have an option listed for setting the
allocated memory, AFAICT.
While using 4Ah seems really odd at first, it becomes almost
"cut-n-paste" thereafter. I first learned how to do that from one
of Ben Lunt's sample programs on his DOS webpages. So, I don't
understand why 4Ah is a huge problem. However, I use NASM mostly
for pure assembly, not TASM, and I generally don't use a linker
for assembly.
Sorry, that's the best I've got on this topic and it's obviously
not much, nor much help.
Rod Pemberton
PS. I haven't seen a post of either of you (Ross, Rudy) in a
while. Unfortunately, you've both been arguing.
news:515c94db$0$6871$e4fe...@news2.news.xs4all.nl...
could provide an appropriate answer.
However, I do have a half dozen different versions of TLINK
around. These were all scrounged from the dark corners of the
Internet... I almost never use TLINK. I have it just in case I
need to compile some code using it. So, TLINK's built-in help
page is about all I know about it's options. That's displayed
when executed without arguments. The oldest (2.0) and newest
(7.1.30.1) versions do not have an option listed for setting the
allocated memory, AFAICT.
While using 4Ah seems really odd at first, it becomes almost
"cut-n-paste" thereafter. I first learned how to do that from one
of Ben Lunt's sample programs on his DOS webpages. So, I don't
understand why 4Ah is a huge problem. However, I use NASM mostly
for pure assembly, not TASM, and I generally don't use a linker
for assembly.
Sorry, that's the best I've got on this topic and it's obviously
not much, nor much help.
Rod Pemberton
PS. I haven't seen a post of either of you (Ross, Rudy) in a
while. Unfortunately, you've both been arguing.
R.Wieser
Apr 8, 2013, 6:48:08 AM4/8/13
to
Hello Rod,
> The oldest (2.0) and newest (7.1.30.1) versions do not have an
> option listed for setting the allocated memory, AFAICT.
My oldest is v1.01 with the newest same as yours, but as you said, they do
not show any option to it. The latter one does however show options as /G
and /P (never used them before), but all I could provoke from them was a
"General error" :-\
> While using 4Ah seems really odd at first, it becomes almost
> "cut-n-paste" thereafter.
Pretty-much the same as I do (I'm using a "basic framework" file for it).
Nothing wrong with not wanting to repeat stuff you think you will always
need.
> So, I don't understand why 4Ah is a huge problem
Its isn't.
Heck, I've even said that I'm using the same myself for COM style files, and
could be using it in EXE style files if the other, in my eyes better, option
is too cumbersome to be used.
What currently is is that my respected opponent, Ross, is so stuck in that
one method that he does not seem to allow himself to think about other
methods, let alone discuss the merrits of them.
And thats the current state of affairs. Ross with his "perfect solution, no
discussion possible" stance with me still weighing all options and looking
at them from different viewpoints.
I still would love to hear about the pros and cons about the different
methods (I have my own thoughts about it, but its possible I did not
consider everything), so I can make an educated decision. But as it now is
I can see that the different solutions have their own merrits, depending on
the position you're in.
> Sorry, that's the best I've got on this topic and it's obviously
> not much, nor much help.
Well, if nothing else you showed me that Borland most likely did not see any
good in programmers being able to manipulate that maxAlloc value. Alas,
they are not around anymore, otherwise I would have loved to hear them
explain.
Thanks for your input,
kjt2bm$u44$1...@speranza.aioe.org...
> The oldest (2.0) and newest (7.1.30.1) versions do not have an
> option listed for setting the allocated memory, AFAICT.
not show any option to it. The latter one does however show options as /G
and /P (never used them before), but all I could provoke from them was a
"General error" :-\
> While using 4Ah seems really odd at first, it becomes almost
> "cut-n-paste" thereafter.
Nothing wrong with not wanting to repeat stuff you think you will always
need.
> So, I don't understand why 4Ah is a huge problem
Heck, I've even said that I'm using the same myself for COM style files, and
could be using it in EXE style files if the other, in my eyes better, option
is too cumbersome to be used.
What currently is is that my respected opponent, Ross, is so stuck in that
one method that he does not seem to allow himself to think about other
methods, let alone discuss the merrits of them.
And thats the current state of affairs. Ross with his "perfect solution, no
discussion possible" stance with me still weighing all options and looking
at them from different viewpoints.
I still would love to hear about the pros and cons about the different
methods (I have my own thoughts about it, but its possible I did not
consider everything), so I can make an educated decision. But as it now is
I can see that the different solutions have their own merrits, depending on
the position you're in.
> Sorry, that's the best I've got on this topic and it's obviously
> not much, nor much help.
good in programmers being able to manipulate that maxAlloc value. Alas,
they are not around anymore, otherwise I would have loved to hear them
explain.
Thanks for your input,
Rudy Wieser
-- Origional message:
Rod Pemberton <do_no...@notemailnotq.cpm> schreef in berichtnieuws
-- Origional message:
kjt2bm$u44$1...@speranza.aioe.org...
Steve
Apr 8, 2013, 8:52:10 AM4/8/13
to
Hi Rudy, Ross,
"R.Wieser" <add...@not.available> writes:
>Ross,
>
>> Steve N already confirmed the fact that most programmers
>> don't set this header value.
>
>He did ? Where ? Not in the two messages he posted in this thread. But
>feel free to quote it (It won't be easy to get what the actually said to
>mean what you think/want it to mean though).
Overstated IIRC. I said; "FTR, I have seen very few programs
a specialized situation in my case. I only need to limit memory
footprint in rare cases.
And I have not seen all that many use the deallocate method
either. And some of them seem to do so because they don't know
how to access already allocated memory.
>> I can also point to the vast majority of the MS-DOS excutables
>> sitting on my machine, from Microsoft's own MS-DOS commands,
>> to countless games and utlities. Countless EXEs all configured to
>> allocate the maximum amount of memory at startup.
>
>Could be true. If it is the first thing I would do would be wondering why
>they did it, and why they kept doing it that way. You do not seem to have
>any such thoughts. Why ?
It is the default behavior of any toolset I know of. How
often do you see people not use the default behavior when it
doesn't hurt? Even if Rudy pointed out that it might be nice
to have it be otherwise. Which started all this this out...
Anyway, you can try it out. If you don't want to use MS's
LINK, you can go to the MASM Forum and serch for other linkers.
(JWLINK and PoLink are used there, possibly others. I don't
know if they support the option to set exMaxAlloc.) And there
are programs to modify the executable's header. EXEMOD is one
that I have used, Though when, where, and why now escape me.
Or use a hex editor. Almost easy.
<Snip>
Regards,
Steve N.
"R.Wieser" <add...@not.available> writes:
>Ross,
>
>> Steve N already confirmed the fact that most programmers
>> don't set this header value.
>
>He did ? Where ? Not in the two messages he posted in this thread. But
>feel free to quote it (It won't be easy to get what the actually said to
>mean what you think/want it to mean though).
actually use the exMaxAlloc method to limit the memory usage."
I only looked at that a few times over the years. And it is
a specialized situation in my case. I only need to limit memory
footprint in rare cases.
And I have not seen all that many use the deallocate method
either. And some of them seem to do so because they don't know
how to access already allocated memory.
>> I can also point to the vast majority of the MS-DOS excutables
>> sitting on my machine, from Microsoft's own MS-DOS commands,
>> to countless games and utlities. Countless EXEs all configured to
>> allocate the maximum amount of memory at startup.
>
>Could be true. If it is the first thing I would do would be wondering why
>they did it, and why they kept doing it that way. You do not seem to have
>any such thoughts. Why ?
often do you see people not use the default behavior when it
doesn't hurt? Even if Rudy pointed out that it might be nice
to have it be otherwise. Which started all this this out...
Anyway, you can try it out. If you don't want to use MS's
LINK, you can go to the MASM Forum and serch for other linkers.
(JWLINK and PoLink are used there, possibly others. I don't
know if they support the option to set exMaxAlloc.) And there
are programs to modify the executable's header. EXEMOD is one
that I have used, Though when, where, and why now escape me.
Or use a hex editor. Almost easy.
<Snip>
Regards,
Steve N.
rug...@gmail.com
Apr 8, 2013, 5:15:08 PM4/8/13
to Bo...@embarq.com
Hi,
On Monday, April 8, 2013 7:52:10 AM UTC-5, Steve wrote:
>
> Overstated IIRC. I said; "FTR, I have seen very
> few programs actually use the exMaxAlloc method to
> limit the memory usage."
I'm not sure this helps, but CWSDPMI (.EXE TSR built with old Borland tools) uses its own hack / tool (ehdrfix.c) to adjust the heap limits (partially from "extern unsigned _stklen" in control.c) in the .EXE header.
/* EXE file header fixer, code taken from Morten Welinder */
...
printf("Usage: ehdrfix cwsdpmi.exe\n Updates heap size in exe header\n");
...
/* Note, the near heap and stack are pooled. EHDRFIX.C reads the lines below */
/* and adds paragraphs required to the exe header. Each task takes 304 bytes */
/* (dpmisim stack + 0x30), each memory zone 14 bytes, each HW int around 850 */
/* paging space flags need 32 bytes per Mb (8Kb for 256Mb max) return unused */
extern unsigned _stklen = 4096U; /* Plus heap added in exe hdr */
Grab CSDPMI7S.ZIP here (if curious):
http://homer.rice.edu/~sandmann/cwsdpmi/index.html
On Monday, April 8, 2013 7:52:10 AM UTC-5, Steve wrote:
>
> Overstated IIRC. I said; "FTR, I have seen very
> few programs actually use the exMaxAlloc method to
> limit the memory usage."
/* EXE file header fixer, code taken from Morten Welinder */
...
printf("Usage: ehdrfix cwsdpmi.exe\n Updates heap size in exe header\n");
...
/* Note, the near heap and stack are pooled. EHDRFIX.C reads the lines below */
/* and adds paragraphs required to the exe header. Each task takes 304 bytes */
/* (dpmisim stack + 0x30), each memory zone 14 bytes, each HW int around 850 */
/* paging space flags need 32 bytes per Mb (8Kb for 256Mb max) return unused */
extern unsigned _stklen = 4096U; /* Plus heap added in exe hdr */
Grab CSDPMI7S.ZIP here (if curious):
http://homer.rice.edu/~sandmann/cwsdpmi/index.html
Ross Ridge
Apr 8, 2013, 8:17:02 PM4/8/13
to
Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
>PS. I haven't seen a post of either of you (Ross, Rudy) in a
>while. Unfortunately, you've both been arguing.
We haven't been arguing. I don't think he's capable of making an
>PS. I haven't seen a post of either of you (Ross, Rudy) in a
>while. Unfortunately, you've both been arguing.
actual argument.
JJ
Apr 8, 2013, 10:12:46 PM4/8/13
to
On Mon, 8 Apr 2013 12:48:08 +0200, R.Wieser wrote:
> My oldest is v1.01 with the newest same as yours, but as you said, they do
> not show any option to it. The latter one does however show options as /G
> and /P (never used them before), but all I could provoke from them was a
> "General error" :-\
Dug my TLINK v3.0 and found undocumented options: /2, /b, /g, and /w. But
> My oldest is v1.01 with the newest same as yours, but as you said, they do
> not show any option to it. The latter one does however show options as /G
> and /P (never used them before), but all I could provoke from them was a
> "General error" :-\
none seem to affect the final EXE. None has optional sub-options like the
/Txx in TLINK v5.x either (checked by dissasemby). :(
> I still would love to hear about the pros and cons about the different
> methods (I have my own thoughts about it, but its possible I did not
> consider everything), so I can make an educated decision. But as it now is
> I can see that the different solutions have their own merrits, depending on
> the position you're in.
the tool for patching the produced EXE?
R.Wieser
Apr 9, 2013, 6:28:40 AM4/9/13
to
Ross,
> I don't think he's capable of making an actual argument.
Funny, I was thinking the same about you.
Your "argument" is that as others have been using it for ages it simply must
be the best one. That is like saying that smoking must be good for you, as
so many people do it.
So, why do *you* think that the method you prefer is the best one ? Can
you actually do the thing you accuse your opponent (me) of of being
incapable of ?
Mind you, I've countered certain aspects of your reasoning (like determining
the actual memory size yourself, instead of simply taking minAlloc, as "the
best"/"the only method") and than not getting any response to it at all.
You do know how that looks, do you.
Ofcourse, you claimed that that minAlloc value was not to be trusted.
Though when I asked(/challenged) you for an example there was the same
absense of a response ...
No pot, I'm afraid that you're trying to call the kettle black. :-)
Regards,
> I don't think he's capable of making an actual argument.
Your "argument" is that as others have been using it for ages it simply must
be the best one. That is like saying that smoking must be good for you, as
so many people do it.
So, why do *you* think that the method you prefer is the best one ? Can
you actually do the thing you accuse your opponent (me) of of being
incapable of ?
Mind you, I've countered certain aspects of your reasoning (like determining
the actual memory size yourself, instead of simply taking minAlloc, as "the
best"/"the only method") and than not getting any response to it at all.
You do know how that looks, do you.
Ofcourse, you claimed that that minAlloc value was not to be trusted.
Though when I asked(/challenged) you for an example there was the same
absense of a response ...
No pot, I'm afraid that you're trying to call the kettle black. :-)
Regards,
Rudy Wieser
-- Origional message:
-- Origional message:
Ross Ridge <rri...@csclub.uwaterloo.ca> schreef in berichtnieuws
kjvmlv$ia6$1...@rumours.uwaterloo.ca...
R.Wieser
Apr 9, 2013, 6:47:21 AM4/9/13
to
Hello JJ,
> Dug my TLINK v3.0 and found undocumented options: /2, /b, /g, and
> /w. But none seem to affect the final EXE.
Thanks for looking at it.
> Why not make a wrapper program to execute TLINK then if all
> is OK, execute the tool for patching the produced EXE?
Yeah, I was also thinking that could be te best solution. Although, as I
remarked in a previous post, it would be for my own programming-environment,
it would not be when I share that source-code with others (they would than
need to create and use a similar tool).
Regards,
> Dug my TLINK v3.0 and found undocumented options: /2, /b, /g, and
> /w. But none seem to affect the final EXE.
> Why not make a wrapper program to execute TLINK then if all
> is OK, execute the tool for patching the produced EXE?
remarked in a previous post, it would be for my own programming-environment,
it would not be when I share that source-code with others (they would than
need to create and use a similar tool).
Regards,
Rudy Wieser
-- Origional message:
-- Origional message:
JJ <jaej...@nah.meh> schreef in berichtnieuws
xisy3h7nfc9r.13...@40tude.net...
0 new messages