I've looked a betovs site, but couldn't find many example sources(didn't very hard either). I seem to remember reading once that someone converted Icz's tuts to Spasm. If so, a link please?

I read that an include directive has not yet been implemented. Can Spasm handle multi-file programming? If so, does it do it better than MASM*.

*I was asm_happy on the old board. Due to my inability to get PUBLIC,EXTERN,EXTERNDEF working properly in MASM, I have ceased using assembly language, until I find an sensible alternative.

I'm not sure if this is a crazy idea, but since assembly programmers like control, it would seem logical to make all data, proc's etc. available across all included files. I don't think assembly people think about data-protection quite as much as C++ programers do. Basically I'm saying make everything global.
Posted on 2001-08-02 20:20:48 by ThoughtCriminal
asm_happy,

for info related to Spasm, you will have to ask Betov, he posts on this forum reasonably regularly so he should be able to answer your questions about it.

MASM questions are another matter. There is no need to make everything global in MASM, it handles both LOCAL and GLOBAL data with no problems, it is fully multimodular in the way it works, it builds Microsoft format library modules with no problems at all.

The syntax for EXTERNDEF is straight forward enough once you get used to it.

pr2 equ <typedef PROTO :DWORD,:DWORD>

externdef _imp__LoadIconA@8:PTR pr2 ; define function as external
LoadIcon equ <_imp__LoadIconA@8> ; normalise the name

Use "invoke" with the function name.

If you have any further questions with MASM, ask in the forum, Betov should be able to help you with Spasm.

Regards,

hutch@pbq.com.au
Posted on 2001-08-02 20:36:20 by hutch--
Scrolling down to the middle of the page you will find many examples in SpASM syntax. Most of the downloads in the section titled 'downloads' are such examples as you seek. :)
Posted on 2001-08-02 21:02:20 by bitRAKE
As BitRake says.

I recommand you, in order: Beginners.zip, TDwin32Tuts, Iczelion.zip.
Most of all, read the Manual and *please* forget what you have
learned with MASM.

"Include" is no use in SpAsm. The Editor have particular features for
moving inside uge mono-files.

For PUBLIC,EXTERN,EXTERNDEF and other red tape, SpAsm have none at
all and will never have any. These key words are usefull when
producing .obj. SpAsm outputs PEs (EXE, DLL, SCR).

Data-protection is good for programmers groups. I have never seen
much reason to do this in Asm. Some Asm programmers do it (Iczelion
is in this opinion), because they want to avoid namings conflicts.
Naming conflicts can never happend in SpAsm because all symbols
have to be unique. If you double declare a symbol, you get an error
message, and, because of the building speed and friendly source error
pointing, this is really not a problem. Another point is that true
meaningless local Labels (A86 style) *can* be redefine as much as
wished. So you will not have to find so much names for short scope
local Labels.Pseudo Local symbols (TASM style) do also exist which
may help a lot, too, for this, when writing reusable Procs.

For the programming style choice (this is to say for the choice of
what Macros set), you might begin with Base3B.exe. It is very close
to what you may have seen.

And, i beg you, report bugs. I can't improve the beast without bugs
reports, because i do always the same things the same way, and most
bugs are seen when performing unregular actions. Any beginner will
be hundread times better than me for this ;)

(V.3.01 released in the comming days).


betov.
Posted on 2001-08-03 02:00:24 by Betov
Modular programming is possible with MASM. Here is an example with two modules. The first is the main module. The second modules defines a function that is called by the main module. The function simply display a message box "In module 1". There is also a Makefile to compile the "project".
Posted on 2001-08-03 07:05:27 by Dr. Manhattan
Nobody was knowing this, Karim. Thanks a lot for the great
enlightement. If you have other such deep knowledge, do not
hesitate to make us know. I took a look at the sources, because
i couldn't believe it, and... found zero error inside. Really
good.

Bye, thanks, betov.
Posted on 2001-08-03 10:09:52 by Betov
Thanks for the replys from both sides. EXTERN, PUBLIC, etc. are kinda legacy from when a large program was 20k lines and compileing the entire program on your 286 took awhile. These days I would not worry about it until >100k. Compiling only the changed obj files and linking with the unchanged probaly saved some time back then.


All I really want is a way to program with multiple files(for my ease of use), but not have to tell the compiler/linker where every thing is(that is defined in another file).


karim, that for that code, seems to make things much simpler. I will still check out Spasm.
Posted on 2001-08-03 18:22:53 by ThoughtCriminal
I don't get the EXTERN and EXTERNDEF things.

I decided to try and recompile a assembly output listing of a C++ app today, and it's called "Vertices" and comes with the DirectX8 SDK.

So anyways, I got the asm file from compiling with listing and then I got the listing.inc file from Vstudio dir, but when I try and compile with MASM, I get unresolved external errors. Can someone explain to me what the heck that means? I only wanted to just play arround with the program using asm, so when I port it, I will know what the heck I'm doing :)

Thanks
Kenny
Posted on 2001-08-03 21:09:34 by Kenny
I just looked though the Game Progamming forum, and got my questions answered, but I still don't get the EXTERN thing, and the topic from Hutch (the one about the new utility that uses externdef) just made things more confusing.

If you can help at all, I'd apprecieate it.
Posted on 2001-08-03 21:44:43 by Kenny
Kenny,

Unresolved externals simply mean that the linker cannot find the functions you are calling in the libraries that are used. You could try the utility I posted on each library that it calls or use the l2inca.exe that comes with masm32 which will make the prototypes in a more conventional way.

I don't know what shape a listing is in from a C compiler or whether it can be set up to build in MASM but I would be surprised if it will build properly without some drastic editing. The bare code may be OK but you have to get all of the equates it uses and the prototypes as well.

Regards,

hutch@pbq.com.au
Posted on 2001-08-04 03:12:11 by hutch--
CoffeeDrinker, I disagree with you :). Having all data public eveywhere
is a bad idea, imho. You might say that "asm programmers want
control", but it's too easy to end up writing spaghetti code if all
your variables are public. At least this holds true for me. Whether
I'm writing in C, asm, or whatever other language.

Probably *the* most important thing when programming a (larger)
application is to do design beforehand, and get the design right.
Modular programming is good and very important, but you have to
get the modules right... otherwise you risk ending up in a situation
where you have just made the job more complicated for yourself...
which is definitely not the idea of modular programming :).


Kenny, EXTERN in itself is pretty easy. What can be pretty annoying
is the various calling conventions and name decorations. Especially
C++ compilers like to decorate names *a lot*. The new externdef
tool from hutch is probably a little more complicated to understand, since it utilizes some knowledge of how imports are
done in the PE file format.
Posted on 2001-08-04 06:03:29 by f0dder
I am not going to start one more Holly war with this, and wish it
purely technical:

There zero technical argument for Modular programming in Asm, as long
as we are not talking of developpement groups.

The concept of reusable routines is out of any reality (out, -like
Bodgan said- of several small, simple and very basic things, like
searching for the length of a zero ended String, that we could as
well Copy/Paste or save in a DLL).

Fodder, you are confusing, "Structured programming" and Modular
programming". There is no reason for what Module would prevent
from spagetti style and there is no reason for 'Non-Modular" to
produce spagetti style.

The simple terms of 'Public' or 'Private' symbols have no place
in Assembly programming because it simply have no reality at
Processor and Memory point of vue. The "scope of symbols", when
this concept is used is is entirely bound to the use of a Linker
and the fact of using any Linker is an old left over from Dos time
that we should definitively forget.

And, to end it, if one think that his routines are so great that
they should be saved somewhere so that the whoole world could
make use of them, we have DLL. If a programmer wants to build
a set of reusable routines that he can call at no cost in several
of his Applications, DLLs are perfect for this, and also *run* at
no cost with an Assembler like SpAsm who performs the Functions
calls in one single instruction.


Betov.
Posted on 2001-08-04 09:40:00 by Betov
Betov, some code is too time sensitive to put in a DLL, even though
they are still reusable. As for only small bits of code being reusable,
I disagree. ZipFile handling code is not small. Generic pakfile (like
the stuff used in doom/quake/whatever) is smaller, but still not small.
These are just two examples of code that can be plugged right out
of one project into another, at least if they're done correctly. If I
were to implement this in DLLs, I would end up with a thousand
small DLLs. If I put it all into one big DLL, I would have one big DLL
to distribute with all my programs...

I'm not confusing modular and structured programming. Perhaps
spasm makes modular programming superfluous with it's features
and all, but I still prefer splitting my source into modules. That way
I can quickly browse to the code I need with *any* editor.
And since I tend to reuse code, it's easier to just copy a "module"
to a new project than copy+pasting various source lines...


The simple terms of 'Public' or 'Private' symbols have no place
in Assembly programming because it simply have no reality at
Processor and Memory point of vue.


There are so many things that have no meaning at processor level
but are still useful. A "proc" doesn't exist on processor level, but
people still seem to prefer using "invoke" and stack automation
compared to manual pushing and indexing via numbers relative to
esp or ebp.

With modular programming, and proper use of public/private, you
make it impossible for one part of the code to call another part that
is really "internal" to another module. Perhaps this doesn't make
sense to you, but I've been involved in projects where this has been
pretty important. Where it has been important to be able to go back
and look at code after months, and still be able to easily work out
the program flow, figure out dependencies, etc. And this applies to
both group projects and single-man projects.
Posted on 2001-08-04 10:13:27 by f0dder
Much interresting answer, Fodder. I see your point as a C programmer
using MASM as C-Side tool. All your arguments are typically from there.
Am i wrong?


Betov.
Posted on 2001-08-04 11:31:53 by Betov
You aren't wrong at all. I think it should hold true for just about any
C compiler... and it also holds true when I do pure asm code. *might*
be different under spasm, but... even with the features I've heard
people talk about (haven't look at spasm yet myself, sorry), I think
I'd still prefer module-splitting. Oh well, personal taste and all.
Posted on 2001-08-04 12:03:40 by f0dder
In this case, let us put aside the problems of Local / Global scope
(what would be difficult to fully debate here -because, for example,
of the solutions offered by what i call "Local Symbols", and so...-).

Can we look at it at the writting practice point of vue. What do you
think of this:

I have plan for futur implementation of "Pseudo-MultiFiles" features
(i don't know how to really call this). SpAsm is really Mono-file
oriented and it will remain. But i could implement something to
allow the user to define "chunks" of code that would appear in the
Source Editor as different files managed by a Tab Control.

The user would, for example, write something like

> .Source "StringsRoutines"

and this chunck, down to next ".Source" Statement would be displayed
the same way as a separate file in a multifile Editor.

Instead of having to paste the Routines Chunks (once saved on disk),
we would just have to run some menu option opening a Load
File Box to import the wished .inc(s).

Out of Code containement (that i will never implement unless i see
one day one reason for this), would this be closer to you usual way
of working?


Betov.
Posted on 2001-08-04 13:51:04 by Betov
Ok quick reply...

First off, I would have to agree with Betov in everything he says. For me LOCAL declarations are more confushing and annoying then they are anything else. I always get confused what local data is where and what is its value in that routine. Confusing to me. For global code, I can always make a messagebox that tells me the data of the code, and then I can look in my program to figure out why :)

But that's not why I'm replying. I can't figure out how to make the EXTERN's referenced. I know some of them belong to various DLL's such as the Kernel32.dll and some DirectX stuff, but I don't understand how to get MASM to know what DLL that is.

If I can do that, the code should compile perfect just outputed of the compiler. The listing files are included.
Posted on 2001-08-04 17:28:11 by Kenny
I have to say that betov is right :)

Reusable code is bad...

we have written one of the largest ASM application (our HE game)
getting close to 300.000 lines of code now...

over the time our greatest enemy was:
1.Copy and Paste errors

it was supposed to help us a lot, and in fact it did save us some typeing work, but the damage was much bigger...

We have a memo here: ITS a COPY AND PASTE ERROR?

BTW. i just wonder why any beginner and C oriented programmer are so much intrested into less typeing?
Unless they are considering this work (witch is bad) and not fun (which is good)


Our second enemy:
Modularization
Because of "organization" we have a lots of "modular" files into diffrent folders.

Each file does specific actions and deals with diffrent parts of our application....I thought its a good ideea at the moment (somehow i still belive it is...damn me ;) )

BUT

Now it is very hard to find one procedure in so many files and it takes us some time until we find ALL links between diffrent modules both physical and (worst) logical...

For example: adding new levels and sublevels of interface buttons has become one of our nightmare ... because of multiple files and logical implications of such changes

Betovs Spasm with its fast link to related procedures could be a magical tool for such problems (only i belive its not good enough yet) but i dont know if the logical ones can ever be solved ...

I still have to see a tool to show ALL physical and logical libks between procedures and variables and files and...

Now its ALL in our HEAD...think what will happen IF we where a huge team (more the 10 ppl like Micro$oft ) and we loose track of those objects, methods etc....GPFaults...so dont balme Micro$oft for this ...... is a programming style problem

So you see Modularization, encapsulation, code reuse and this stuff are not necesary good....strange enough this is true esp for huge applications

They work well for tiny applications....but leave you in need for the real huge ones ...

And Fodder you are wrong again:

There is a PROC at the hardware processor level: CALL/RET and Stack mechanism (they added ENTER and LEAVE there lately)

"invoke" and such are just MACROs to make your life easy, but the mechanism is there allready and was there form the first micros like I8080 and Z80 :)


Besides we should stop those Crusades here and try to help ppl witch ask a Question and get confused by bigger answers then the question originally was

As Huch said it one beginner can NOT expect a direct compile of asm generated from a C++ compiler to work seamless into MASM....

It will not work because of constants, equates, #defines, header files (mostly), linker symbols and stuff like that...

but the code will be relative OK, one can use it as a source for inspiration or a tip but not for a full ASM application ;)

At least Not without some work...

The C compiler/linker knows by default a lots of things, and it chooses NOT to tell you (the programmer) about them...efectively cutting your knowledge...

Converting header files into asm include files can be a problem of its own (and not for beginners). To do that one must know C++ and ASM resonably well

However this can be done ;)

Once again i have to point it out that helpers like LOCALS. .IF .WHILE and such are a big problem for beginners and get them confused...

Once you have written 1000 "while style" loops and "ifs" like:

cmp eax,
jbe there

one medium user will find the above helpers pretty handy and usefull but this comes AFTER one has the full knowledge of whats behind them
Posted on 2001-08-04 18:38:55 by BogdanOntanu
Reusable code != copy & paste

they did invent calls and dlls for a reason now :tongue:
Posted on 2001-08-04 20:34:36 by Hiroshimator
Yeah Hiro i know that

C&P != reuseable code

but its a basic form of it ...the one that is bad if i might say ;)

But hellas, not all code can be placed in a DLL or called with parameters because one will get into over parametrization of routines and loose speed because of that....

in a huge application most of the routines do allmost the same thing but with slightly diffrent actions and on very diffrent data

C&P looked as the right solution then and is very tempting today ;)

I mean we say/think : "eh...it looks i have done this stuff before into that section of our code... i will just C&P that routine here, modify it until it fits this new purpose and get by with less work, after all why should i rewrite it from scratch?"...wrong so wrong..but so tempting also

every problem has a simple,elegant and easy solution...that is also wrong ;)

we sure use CALLs to procedures a lot (with register or temporary global parameters avoiding stack parameters if possible for speed) and played with functions in DLL also (for compiled sprites), Macros come handy sometimes also...

We just have to see the tools for huge applications (huge at code/algorithms level not filesize ;) ) be born...and i mean for every language not ASM only ;)

Curently the best tool available is our Brain ... and the .lst file
Posted on 2001-08-04 21:07:26 by BogdanOntanu