linking c function with masm caller

[dedndave]

well - that is a new instance of CMD.EXE
the temporaries are lost when you close the console window
to make them permanent, you have to go through the System cpl in the control panel or through the registry

[donkey]

Hi everyone -

I'm not clear on the two comments regarding PROTO C.  The discussion here was a bit unclear.  In the original snippet I sent, I sent a asm program that had no PROTO C proto.  In an earlier version of the code, I in fact incorporated the C modifier.  Didn't seem to fix anything, and in fact, I have been able to get the subroutine to function appropiately without including the C modifier in the asm caller. 

So, maybeI don't understand quite the statement that "in this case it was not correct".  Perhaps not, but the code seems to run even if the PROTO statement could be made more precise with the inclusion of the "C" modifier.
...

Hi Mark,

When using a C function the caller is obliged to balance the stack after the call, normally INVOKE will do this for you in MASM as long as it is informed that the call adheres to the C calling convention. In order to do that you must include the [langtype] directive in your PROTO definition. In you original post you had this:

Code Select Expand

summer PROTO :DWORD, :DWORD

This will inform MASM that it is to expect a STDCALL (modified RTL pascal) function and the stack will not be balanced after the call which is incorrect. Vortex corrected it in his post:

Code Select Expand

summer PROTO C :DWORD,:DWORD

Regardless of whether it fixed all of the problems you were having, the language directive still has to be set properly, the fact that it did not seem to solve the problem just means that it was not the only one. I did not look at the code you uploaded, only what was in the post since I don't bother much with MASM code (GoAsm does not use protos or libs) and was simply commenting on Greg's post.

Edgar

[allynm]

Hi everyone-

I looked over what dedndave did, and it looks like the right way to restore the original functionality after setting the paths.  And it could all be stashed in a bat file.  So, it's pretty cool.

I finally "got it" as far as including the C modifier in the Proc statement.  I will in future make this a standard.  Thanks for clarifying this point.  And, yes, there were other problems sinking my ship.

One point that would be helpful to me since I am new to setting environments is what exactly happens when you do something like this:

  set path=c:\etc, etc,;%PATH% 

I don't understand what sticking the %PATH% variable at the end accomplishes.  It's probably simple, but it isn't clear.  I also don't understand why quotation marks are sometimes used and sometimes not.  If anybody cares to elucidate this, I would find it most helpful.

What I ended up doing was to reset the permanent path, lib, and includes in the environment so that they would automatically be available in my masm directory.  In other words, I quit messing around with temporarily changing these variables the way Vortex suggested, and just put them into the permanent environment.  They work nicely that way and there is no problem with restoring Notepoad at the end of a buiild.

Thanks to all,
Mark

[donkey]

I don't understand what sticking the %PATH% variable at the end accomplishes.  It's probably simple, but it isn't clear.  I also don't understand why quotation marks are sometimes used and sometimes not.  If anybody cares to elucidate this, I would find it most helpful.

You use %PATH% because you want to add the folder to the current path, not completely replace it. Quotes are usually used when there is a space or other delimiter in the path.

[Vortex]

Hi Mark,

Code Select Expand

set path=c:\etc, etc,;%PATH%

c:\etc means that there is a directory named etc in the root of your drive C
The second etc means that there is subfolder named etc in your current directory.

The %PATH% expression will be expanded to the current path info. Let's have a look in this example :

Code Select Expand

set path=C:\MyFirstDir

path

PATH=C:\MyFirstDir

set path=C:\MySecondDir;%PATH%

path

PATH=C:\MySecondDir;C:\MyFirstDir

It's not obligatory to enclose the paths between double quotes.

[dedndave]

commas should not appear in the path variable
and, it is generally considered good practice to reference all paths completely, including the drive

when you do something like this...

set PATH=C:\MyNewPath\Folder;%PATH%

or

set PATH=%PATH%;C:\MyNewPath\Folder

the new folder is appended to the current PATH variable
placing the new path first means windows will look in that folder first for the executable or batch command
that can make a difference if there are executables in other folders in the PATH variable that are named the same
in days of old, it used to speed things up for earlier named folders, as well
that is no longer true, as the directories of these folders gets cached anyways

[jj2007]

It's not obligatory to enclose the paths between double quotes.

set path="C:\Programmi\Microsoft Visual Studio 9.0\Common7\IDE";%path%     throws a "mspdb80.dll not found error"
set path=C:\Programmi\Microsoft Visual Studio 9.0\Common7\IDE;%path%     works fine.

[z941998]

Old Dos convention - 8 char (filename) and 3 char (ext).

Use the tilde key (~) in the eigth char for all directories that are longer than 8 chars.

Also, spaces in the names need to be quoted, else the space creates tokens persay, versus path info.

[jj2007]

Old Dos convention - 8 char (filename) and 3 char (ext).

Use the tilde key (~) in the eigth char for all directories that are longer than 8 chars.

You should test your advice before posting in the Campus. Even if there was only one folder starting with MICROS, it would still be the seventh, not the eight char.

C:\PROGRA~1\MICROS~2.0
C:\Program Files\Microsoft Not so Visual Crap 1.0

C:\PROGRA~1\MICROS~1.0
C:\Program Files\Microsoft Visual Studio 9.0

> Also, spaces in the names need to be quoted, else the space creates tokens persay, versus path info.
See my post before. There is no need to quote long path names with spaces.

[donkey]

Old Dos convention - 8 char (filename) and 3 char (ext).

Use the tilde key (~) in the eigth char for all directories that are longer than 8 chars.

Also, spaces in the names need to be quoted, else the space creates tokens persay, versus path info.

Actually the tilde (~) can be on any character though it is generally on the 7th or 8th and can be followed by a number (ie PROGRA~1) in order to distinguish between items that have the first 8 characters in common. If you want to get the actual short name you need to use the GetShortPathName function or from Windows using DIR from the command prompt with the /x switch.

[dedndave]

C:\PROGRA~1\MICROS~2.0
C:\Program Files\Microsoft Not so Visual Crap 1.0

C:\PROGRA~1\MICROS~1.0
C:\Program Files\Microsoft Visual Studio 9.0

normally, it would be like this

C:\PROGRA~1\MICROS~[N]
C:\PROGRA~1\MICROS~[N]

where [N] is an incremented value based on on the order of folder creation (or recognition)
the period in folder names is treated similar to file extensions in that it becomes a new name section
when it reaches a 2-digit value...

C:\PROGRA~1\MICRO~[NN]

when it reaches a 3-digit value...

C:\PROGRA~1\MICR~[NNN]

and so on

See my post before. There is no need to quote long path names with spaces.

i am pretty sure that depends on which batch command you are using
some batch commands recognize spaces as parameter delimiters

[jj2007]

...
where [N] is an incremented value based on on the order of folder creation (or recognition)
the period in folder names is treated similar to file extensions in that it becomes a new name section
when it reaches a 2-digit value...

C:\PROGRA~1\MICRO~[NN]

That is correct, to my knowledge. I obtained my example paths with an equivalent to GetShortPathName. Caution with the dir /x variant, it yields this on my machine, XP SP2:

25.01.10  15:38    <DIR>          MICROS~2.0   Microsoft Not so Visual Crap 1.0
14.01.10  16:38    <DIR>          MICROS~2     Microsoft Office
30.11.05  16:01    <DIR>          MICROS~3     Microsoft Visual Studio
05.01.10  13:30    <DIR>          MICROS~1.0   Microsoft Visual Studio 9.0

See my post before. There is no need to quote long path names with spaces.

i am pretty sure that depends on which batch command you are using
some batch commands recognize spaces as parameter delimiters

That is correct but rarely relevant since the path starts with an executable, not with parameters.