Re: Reply to Beth.
- From: "hutch--" <hutch@xxxxxxxxx>
- Date: 19 Jul 2005 20:53:10 -0700
Randy,
Thanks, you have some interesting comments here. I responded to Beth
seperately as I see her as sensible and would like to see the LuxAsm
team get a viable result in a lifetime. Its a convergence versus a
divergence distinction where producing a viabe working end result is
worth more that having an infinitely flexible idea that is never
implimented.
If a decent 64 bit version of MASM is produced which we are yet to see,
the architecture of a 64 bit MASM project will need a complete rethink
as it is structurally different in a number of important things but I
see large problems with fiddling with the current 32 bit version as it
has consistency and backwards compatibility going for it.
It can still build example that were written over 7 years ago and to
this extent the low level structure of Windows has not changed much at
all. One of the hardest things to do has been to maintain the
neutrality of the system that it uses so that different people can
extend it in the direction they require without being commited to any
particular method of building applications.
It is a trivial task to pipe the results of the assembler, resource
compiler and linker to an IDE but in doing so, it hides something from
the programmer that they need to properly understand and this is the
command line nature of the appropriate tools. By maintaining the batch
file format, programmers who want to use the VC ide, RadAsm, WinAsm
studio and the like are not commited to one particular method.
It is a technically trivial matter to modify the tool I use to create
the include files for the API functions to specify the STDCALL
convention explicitly but it comes at a cost of ML carrying over 12000
extra pieces of data when the vast majority of API calls are STDCALL. A
number of years ago I modfied the format of the include files so that
instead of only ANSI prototypes, both UNICODE and ANSI were supported.
The cost in terms of programmer convenience is that they must specify
the calling convention of procedures that are not STDCALL but this is
hardly a big deal.
MyProc PROTO :args etc ...
versus
MyProc PROTO Pascal :args etc .....
Forcing an assembler to hold over 12000 additional data items is
certainly a lot more work that altering a few prototypes writen one at
a time so I am yet to see the point of explicitly setting all of the
API calls to STDCALL.
The direction MASM32 development is going in is extending the range of
reusable code in libraries and trying to leverage at least some of the
power of preprocessor code so that both learner programmers can get
from entry to production faster and the very experienced programmers
with a C background can exercise the additional control and power of a
decent preprocessor.
As an aside, the preprocessor in MASM is not without its irritations
but I keep in mind that it is the internal parsing engine in MASM and
it was not directly designed to be a user friendly scripting language.
Notwithstanding such irritations I am of the view that it has only ever
been partially utilised and there is a lot of room to keep producing
mixed library and preprocessor code that dramatically increased the
speed and convenience of good quality binary code.
Regards,
hutch at movsd dot com
.
- References:
- Reply to Beth.
- From: hutch--
- Re: Reply to Beth.
- From: randyhyde
- Reply to Beth.
- Prev by Date: Re: f0dder's Fabulous Follies (Part 3)
- Next by Date: HLA Adventure just got converted to 4 new platforms today
- Previous by thread: Re: Reply to Beth.
- Next by thread: f0dder's Fabulous Follies (Part 3)
- Index(es):
Relevant Pages
|
