News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Compatibility of headers with Microsoft MASM

Started by Adamanteus, December 09, 2007, 02:30:46 PM

Previous topic - Next topic

Adamanteus

 I'm changing from 16 bits MASM 6.1 on MASM32 6.1 and marked not good compatibility of header files. Include and library files Microsoft's puts by path of environment variables, so them possible to put in any directories, why in the MASM32 version outgown from this rule and there evryware \masm32\include\...

hutch--

Hi Adamanteus,

Welcome on board. It was done this way for a reason, many masm programmers have different libraries in different environments like VC and similar and t9 avoid getting the wrong libraries, linker etc ... the paths were hard coded so when you built a MASM exe, dll or obj modul;e, you get the libraries and binaries for MASM, not another environment.

I run multiple versions of Microsoft CL.EXE C compiler the same way and by doing i this way I can use multiple setups to do what I need.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Adamanteus

But by this way occupied place for assembler and libraries disk:\masm32\.. and it's not useful. It is easy to avoid by need changing headers and installer. May be better universality then originality !?

jj2007

Quote from: Adamanteus on December 09, 2007, 04:54:42 PM
But by this way occupied place for assembler and libraries disk:\masm32\.. and it's not useful. It is easy to avoid by need changing headers and installer. May be better universality then originality !?
Not useful? Try this:

- create an environment variable MasmPath following the instructions at http://support.microsoft.com/kb/310519
- put this into a batch file:
@echo off
echo MasmPath="%MasmPath%"
echo Hit Enter to get outta here
pause >NUL

On my XP Prof here the environment variable is not visible...
I find a hard-coded \Masm32 path extremely useful. Let's vote?

u

I'm in for hardcoded paths. And anyway when you make a .lib to merge with a C++ project, you still have the option to selectively avoid such paths.
Please use a smaller graphic in your signature.

Vortex

Me too, I vote for hard coded paths. This method makes life easier.

MichaelW

I too prefer hard-coded paths. In the past I have had too many problems with incorrect paths, and wasted too much time trying to manage my paths to ensure that everything would work correctly. I have developed a strong dislike for tools that modify my system configuration.
eschew obfuscation

ToutEnMasm

Hello,
Without modifying system path,the chain environment can be modified to use differents builds.
This chains are include,lib,ML,PATH,LINK.
We can put searching paths in this chains (furthers paths are allowed).Source code can be write without hardcoded path and a source can be build with VC,masm,SDK,DDK...builds environment without change of the source.
Each different build environment can be copied in msdos chains for reuse with masm.

Adamanteus

QuoteSource code can be write without hardcoded path
How it could be write it's clear  :boohoo: - question is : How it's wrote ?
It is impossible to hold masm32 library, because it's fit to hardcoded paths !?

Tedd

I have MASM_HOME defined as an (global) environment variable, and then ml/link/rc/etc are all in "%MASM_HOME%\bin\", .inc files in "%MASM_HOME%\include\" and .lib in "%MASM_HOME%\lib\"
These paths are then 'hardcoded' into the .bat files, with search paths given to ml (/I), link (/LIBPATH), and rc (/i) - removing the need for the paths in source files.
No snowflake in an avalanche feels responsible.

ToutEnMasm

You can modify the environment with differents ways.
In a batch
Quote
@echo on
REM /Zp[n] Set structure alignment

SET PATH
setlocal
SET PATH=\masm32\bin
SET INCLUDE=\masm32\include
SET LIB=\masm32\lib
SET ML=/c /coff /Zp4
SET LINK=/SUBSYSTEM:WINDOWS
REM ///////////////////////////////////////////////////////
SET PROG=MYPROG
REM ///////////////////////////////////////////////////////

rc /v  %PROG%.rc
cvtres /MACHINE:IX86 /OUT:%PROG%.bin %PROG%.res
ml  %PROG%.asm
Link  %PROG%.obj %PROG%.bin
pause

jj2007

Quote from: ToutEnMasm on December 11, 2007, 03:02:15 PM
You can modify the environment with differents ways.
Sure. But Windows has made the creation of global environment variables pretty clumsy and messy - try a google search for "environment variables" global
So whenever you sent your code where lib=MyMasm\MyLib to member X who has the libs somewhere else, X must either modify your batch files or rely on a messy global environment variables setting.
Besides, I do not see any advantage of having Masm32 sit in X:\my long path with spaces\asm\masm32...

ToutEnMasm

The paths in the batch are the standard paths for masm and the batch can work in any disk with masm on it.
If Some peoples want to used another path,they create themself a problem.
I don't like problems and used always the standard path.But it's not difficult to change a path in a batch.
You can also create further path separating them by a ;.
You can also used API to modify them (GetEnvironmentVariable).

Modifying three path in a batch is easier than changing paths in a source code,paths can be numerous here.


Adamanteus

This problems easy solves reg files, I'm using them - attached.
But who advised chain environment by batch files, I marked that this option of system not ever working the same, may be exist some tips of fine turn it ? Or it probably depends on build number of OS ?

[attachment deleted by admin]

ToutEnMasm

Not a very good idea to use them.You modify system path used by other IDE.
Advantage of chain environment is that changes return to the original state when the batch or the program is closed.
Problems can exist when using the "\program files" path that have different for each country
the
Quote
ProgramFiles=C:\Program Files
solve this.Masm don't used it.If you have to do that,change your path like that
Quote
C:\Program Files\CHAT
%ProgramFiles%\CHAT