🚀 go-pugleaf

Daniel deLesdernier wrote:

>.386p

You forgot the Model

>PUBLIC _externproc

I prefer to put my Publics in the same segment as the actual label.
CODESEG
    PUBLIC	_externproc

>DATASEG
>_asmNum DD 0505Ah;just to see if this works
>ENDS _DATA
>CODESEG
>start:
>_externproc PROC
>mov as, 05h

That's not an instruction.

>ret
>-externproc ENDP

Wrong, probably because you typed it in.
Always use copy/paste for code.

>ENDS _TEXT
>END start

Illegal for subroutine modules.
"END start" is for stand-alone applications such as the original *.com files
Use just plain end
	end	;End Of File


>void __fastcall TForm1::Button1Click(TObject *Sender)
>{
>int num1=78;
>int num2=0;
>char *myChar[1];
>Form1->Edit1->Text="6";

Please use Asm blocks:
asm{	code
	code
        };

>asm mov eax,num1

Redundant as you immediately overwrite eax in the next instruction

>asm mov eax, 0Ah
>asm mov num2,eax

Much easier to do
	mov	num2,0ah

>asm mov eax,0FFh
>asm mov myChar, eax

Not a good idea.
myChar now points to memory location 0xFF

>extern "C" void externproc();

Correct.

>This version actually compiles, links, and runs!!! But why?

Why not?

>Also, PUBLIC _externproc is necessary, I think, to get the linker to find
>the function implementation since it is not in the cpp file. What is it you
>said about the PUBLIC directive putting something in a symbol table? What's
>a symbol table?

In ASM, everything in your code is private to the file unless you explicitly
say otherwise.  In C/C++, everthing is Public unless told otherwise.

When the assembler creates the OBJ file, it won't put in anything
telling the linker the names of the private items.  The place where
the assembler (or any compiler of that matter) places those names
is called the symbol table, and is a part of the OBJ file.

In order for any other module to see _externproc, you must tell the
assembler that you mean to share it.

> Are there
>advantages to not using the simplified directives?

You can have more control, but most of the time, the default behaviour
of the simplified directives is more than adequate.
Ed likes to wield total control over his ASM.

>Can you use CODESEG and DATASEG multiple times in a source file?

Yes, and don't forget the UDATASEG for those uninitialized variables.
Hard coded empty arrays should go in the UDATASEG so they don't
take up space in the EXE file.