Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #4092
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Newsgroups | comp.os.msdos.programmer |
| Subject | Re: initial memory |
| Date | 2021-12-04 13:12 +0100 |
| Organization | . . . |
| Message-ID | <sofluh$1la0$1@gioia.aioe.org> (permalink) |
| References | (2 earlier) <da470e5b-c79a-4f5d-add7-9d7ea0a313a0n@googlegroups.com> <soclec$tcv$1@gioia.aioe.org> <18xw4wam0sv01$.15vxgi1xg9ahw.dlg@40tude.net> <sof98p$ihu$1@gioia.aioe.org> <sofle0$1i11$1@gioia.aioe.org> |
2021-12-04 at 13:00 +0100, R.Wieser wrote: > In the case of Borlands Tasm it seems to be by design. And with no > option to override *I* had to "fiddle" the EXE headers. :-\ Still, the Tasm tool does it on purpose. It has choice, it just decides oterwise. When dealing with COM files, there is no choice. > And pardon me saying so, but how is "by design" *not* "on purpose" :-) The design of the COM-style loading led to simplistic stack sizing and allocation. I doubt COM loading was designed with the specific goal of allocating a full 64K of memory with stack at the end - it was just a consequence of an earlier design choice. In the case of EXE files, there are headers to deal with this situation. A tool that sets the headers in a specific way does so on purpose. Mateusz
Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-02 14:07 -0800
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-03 15:05 +0700
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 00:38 -0800
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-03 09:45 +0100
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 01:22 -0800
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:00 +0700
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 08:39 +0100
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 09:35 +0100
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 13:00 +0100
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 13:12 +0100
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 15:55 +0100
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 16:30 +0100
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 18:11 +0100
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-04 19:04 +0100
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-04 21:02 +0100
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:01 -0800
Re: initial memory Mateusz Viste <mateusz@xyz.invalid> - 2021-12-06 09:27 +0100
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:03 +0700
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-04 14:01 +0700
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-04 02:00 -0800
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-05 14:12 +0700
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-05 15:02 -0800
Re: initial memory JJ <jj4public@gmail.com> - 2021-12-06 13:28 +0700
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 11:25 +0100
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 03:18 -0800
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 14:19 +0100
Re: initial memory "muta...@gmail.com" <mutazilah@gmail.com> - 2021-12-03 11:35 -0800
Re: initial memory "R.Wieser" <address@not.available> - 2021-12-03 22:30 +0100
Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:32 +0100
Re: initial memory - SS:SP "R.Wieser" <address@not.available> - 2021-12-06 14:51 +0100
csiph-web