Author
Topic: having difficulty with extern (Read 4774 times)

Ok, I hope this is the last major question I have here after putting low of rudimentary question. I tried to do a correct usage of extern and public in two different files and both of them compiles and generates obj files but during link the proc declared as public (lib.asm) and imported into second file (asmfile.asm) with extern directive is causing issue. I re-checked everything and corrected but still it is giving a grief. Can someone help on this?

After compilation, I am not sure if the code segment of lib.asm were included in the binary (need to check that) but for sure, data segment of lib.asm was included by dumping the area with debugger.

Thanks in advance!

C:\git\minix.dev>dir Volume in drive C has no label. Volume Serial Number is FC76-C34F

ok - i don't have any experience using masm 6.x + with 16-bit libraries - lol

the last time i wrote libs/eternal objs for 16-bit, i was using masm 5.10 and a linker from the same era

but, i have written a little static library example using 6.x, for 32-bit codeseems like the directives should also work for 16-bit code

first, i notice that you are creating your own segments, like we did in the old daysthat's a lot of work - lolbut, it should be do-ableeasier to use:.STACK 4096 for 4 KB stack (as an example).DATA for initialized data.DATA? for uninitialized data.CONST for read-only initialized data.CODE for code@Data to load DGROUP into a register

no more text segment para blah blah blahno more ENDS, either - when you open another segment, the current one is closed

that having been said, i will find the 32-bit example for you to look atyou can throw out EXTRN and PUBLIC, and just use EXTERNDEF for both

ok - i don't have any experience using masm 6.x + with 16-bit libraries - lol

the last time i wrote libs/eternal objs for 16-bit, i was using masm 5.10 and a linker from the same era

but, i have written a little static library example using 6.x, for 32-bit codeseems like the directives should also work for 16-bit code

first, i notice that you are creating your own segments, like we did in the old daysthat's a lot of work - lolbut, it should be do-ableeasier to use:.STACK 4096 for 4 KB stack (as an example).DATA for initialized data.DATA? for uninitialized data.CONST for read-only initialized data.CODE for code@Data to load DGROUP into a register

no more text segment para blah blah blahno more ENDS, either - when you open another segment, the current one is closed

that having been said, i will find the 32-bit example for you to look atyou can throw out EXTRN and PUBLIC, and just use EXTERNDEF for both

will externdef will work for both in the current style of programming? I will give it a try. thanks.,

great, using externdef it worked. I had to declare inside the cseg in order for it work. I am not sure why public and extern did not work. Tutorial says externdef will either act like extern or public depending whether the symbol exists in the file or not.If so, only logical reason it did not work is might be public/extern was declared outside the cseg. That is what the online tutorial shows. Might that was typo?Who knows.

yes i noticed, however i just included in the macro as externdef proc1:near etc., it does not seem to hurt (compiler did not complain) when used as a public statement too.So the potential benefit seems to outweight to avoid maintenance nightmare of keeping track of all externdef variable, functions etc.,Just declare the macro in your new module and every externdef is included.Anything add to be used externally, just add to macro.Might not be a big deal when having a few files, but when you have 100 files.

FWIW, there's no particular reason to use a macro. Normally we just put all the externdef's in an include file, and include that file at the top of each module. Using a macro as you do, it still must be in an include file, which still must be included, plus you then have to invoke the macro. Only advantage, if you want to include the file for other reasons, but not the externdef's, you can not invoke the macro; but that doesn't seem too useful. So, you can just skip the "EXTERN1" macro definition