Why using includelib?

[Sergiu FUNIERU]

How did you get rid of Warning! W1107: undefined system name: nt ?

I didn't see that error message. I attached below what I see when I assemble the index.asm file. I use Windows Vista, Home Premium, in case it makes a difference.

By the way: include c:\masm32\include\windows.inc is a bad habit, since many members have installed Masm32 on another drive. Please use include \masm32\include\windows.inc

I agree that is a bad habit.

I installed JWasm on the drive C. I create a separate virtual drive for each language I'm working with.
For instance, issuing this command:
subst y: c:\asm_source
I have a letter reserved only to asm.

I do this because I work on a single project at a time and for me is simpler this way. If I use \masm32 instead of c:\masm32, I will get errors, because the source is on drive y, and there is nothing in the y:\masm32 folder.

I'm planning to do this:
set include_path = c:\masm32\include
include %include_path%\windows.inc

I know that the above syntax is not the right one, and I was planning to ask that question in a separate thread.

[jj2007]

How did you get rid of Warning! W1107: undefined system name: nt ?

I didn't see that error message. I attached below what I see when I assemble the index.asm file. I use Windows Vista, Home Premium, in case it makes a difference.

Thanks, Sergiu. In the meantime, I found out that there is a file \masm32\bin\wlink.lnk containing the necessary paths. The lnk extension is quite misleading, but it actually opens in a test editor.

Re include paths, it is assumed that your asm sources reside on the same drive as your masm32 installation - hence no need for a drive letter, and no need for environment variables. Not sticking to this rule means reducing the number of responses to your posts.

[Sergiu FUNIERU]

Thanks, Sergiu.

I thank you.

Re include paths, it is assumed that your asm sources reside on the same drive as your masm32 installation - hence no need for a drive letter, and no need for environment variables. Not sticking to this rule means reducing the number of responses to your posts.

My includelib statements are all disabled in the index.asm I posted. Yet, it still works.

By the way, 1 minute ago I tried with relative path, running all from c: drive. The result was the same.

[jj2007]

My includelib statements are all disabled in the index.asm I posted. Yet, it still works.

It works for this particular case because wlink.lnk contains the info about the libraries to include. Masm needs the includelib statements but does not need an extra configuration file - in my opinion the better way.

system begin nt
    option osname='Windows NT character-mode'
    libpath \masm32\lib
    library kernel32,user32,gdi32,msvcrt.lib
    op stack=0x40000
    format windows nt ^
    runtime console=4.0
end

[Sergiu FUNIERU]

In the meantime, I found out that there is a file \masm32\bin\wlink.lnk containing the necessary paths. The lnk extension is quite misleading, but it actually opens in a test editor.

I believe that the lnk extension chosen for WLink's configuration files is an unfortunate coincidence with the Windows's extension for shortcuts.
However, the lnk extension for your configuration file is assumed if you don't specify one. So, you can use a MySettings.txt file if you wish, which you can easily open in a plain text editor.

I found this in the WLink manual:
The default name of the linker directive file (wlink.lnk) can be overridden by the WLINK_LNK environment variable. If the specified file can't be opened, the default file name will be used. For example, if the WLINK_LNK environment variable is defined as follows

Code Select Expand

set WLINK_LNK=my.lnk
then the Open Watcom Linker will attempt to use a my.lnk directive file, and if that file cannot be opened, the linker will revert to using the default wlink.lnk file.[/i]

[Sergiu FUNIERU]

In the meantime, I found out that there is a file \masm32\bin\wlink.lnk containing the necessary paths. The lnk extension is quite misleading, but it actually opens in a test editor.

I believe that the lnk extension chosen for WLink's configuration files is an unfortunate coincidence with the Windows's extension for shortcuts.
However, the lnk extension for your configuration file is assumed if you don't specify one. So, you can use a MySettings.txt file if you wish, which you can easily open in a plain text editor.

I found this in the WLink manual:
The default name of the linker directive file (wlink.lnk) can be overridden by the WLINK_LNK environment variable. If the specified file can't be opened, the default file name will be used. For example, if the WLINK_LNK environment variable is defined as follows

Code Select Expand

set WLINK_LNK=my.lnk
then the Open Watcom Linker will attempt to use a my.lnk directive file, and if that file cannot be opened, the linker will revert to using the default wlink.lnk file.


You also can import the file from the attached archive and run it. It will add a "Edit with NotePad" option in the right click menu for .lnk files. Of course, the .reg file from the archive can be customized, that is you can use your proffered text editor instead of NotePad.