Should we improve the Masm64 SDK?

[Vortex]

Hi Caché,

Thanks for your reply. While an assembler and a compiler are different tools, your description is nice. ml.exe with a powerful macro engine is similar to a mini compiler.

We have to respect Hutch's legacy. Some parts of the Masm64 package can be rebuilt. We should keep alive Hutch's projects, that will be our mission.

[zedd151]

We have to respect Hutch's legacy. Some parts of the Masm64 package can be rebuilt. We should keep alive Hutch's projects, that will be our mission.

Hi Vortex, that is or should be the main objective. Some folks here keep implying that the SDK should be made compatible with Uasm. That should not be the case. Hutch never wanted that, and he loathed just the suggestion of making either of the SDK's compatible with the Watcom based assemblers. This goes back years, that he has felt this way. All one needs to do is search "Watcom" and use "hutch--" in the Member field of advanced search here on the forum.

The same goes for the "open source", or as hutch put it, "open sauce", crowd here, keep wanting the 64 bit SDK to be placed on github, or sourceforge, or otherwise be put under the GPL licensing. Hutch had purposely written the licenses for the SDK's so that it prevents that from ever happening. That is my read on that part.

The include files need a bit of work, and the macros in the SDK as well. There are some leftovers also that need to be fixed, from the time when Masm64 was originally installed inside of the Masm32 directory, there are some batch files and sources in the examples folder that still reference the Masm32 directory path, for example.

zedd

[jj2007]

Some folks here keep implying that the SDK should be made compatible with Uasm.

Indeed, being able to use an assembler that is 5 times as fast might be useful for those who have real projects.

The include files need a bit of work, and the macros in the SDK as well. There are some leftovers also that need to be fixed

If you start working right now, maybe we'll see some results for Christmas?

[HSE]

that is 5 times as fast might be useful for those who have real projects.

Real projects are build with modules and libraries. Anyway, velocity is perhaps most irrelevant assembler feature.

[jj2007]

that is 5 times as fast might be useful for those who have real projects.

Real projects are build with modules and libraries. Anyway, velocity is perhaps most irrelevant assembler feature.

My experience is different. From building a 20 lines source (which obviously uses "modules and libraries"):

*** Assemble using mlv15  ***
 Assembling: tmp_file.asm
*** MasmBasic version 23.09.2023 ***
## MasmBasic GUI build ##
## creating 1 controls ##

*** Link  IdaDlg.obj rsrc.res  using polink, sub WINDOWS ***
*** IdaDlg.exe: 61952 bytes ***

*** build all took 3520 ms ***
« OK »

*** Assemble using UAsm64  ***
*** MasmBasic version 23.09.2023 ***
## MasmBasic GUI build ##
## creating 1 controls ##
Tmp_File.asm: 20 lines, 3 passes, 129 ms, 0 warnings, 0 errors

*** Link  IdaDlg.obj rsrc.res  using polink, sub WINDOWS ***
*** IdaDlg.exe: 61440 bytes ***

*** build all took 347 ms ***
--------------- OK ---------------

[daydreamer]

Thanks cache gb

Hope this doesnt end in old discussion assemble vs compile
You parse text and output .exe with both
I prefer macro assembler,cpp compiler auto align data breaks my simd code

Jochen and hector,i like uasm,but those millis timings vary much depending on fast ssd,slower mechanical drive,usb drive and older computer= older slower hd

[Caché GB]

daydreamer
I programme assembly using MASM in Visual Studio. To start a MASM project I need to add:
Project -> Build Customizations and click checkbox "masm(.targets, .props)"
So I'am pure MASM. I do not like compilers, and I know nothing about Watcom.

Hutch's legacy will always be respected by me.

I say we should first concentrate on an Include File Base like the one in Windows Kits (10.0.14393.0).
Once the Include File Base has a good grounding, work can begin on the runtime dll and stactic lib.

So all a MASM coder would have to do:

include windows.inc      ; shoot a'n skoot

If in MASM the coder wanted to goof around with some DirectX D2D

include windows.inc
include d2d1_2.inc       ; add Windows Core -> now do D2D stuff

Later, Frameworks can be developed around the Include File Base and the SDK's runtime and stactic libs.

include windows.inc
include d3d11_1.inc      ; add Windows Core -> now do D3D stuff
include ObjAsm.inc       ; add ObjAsm Framework. (By Biterider @ http://objasm.x10host.com/ )

And if the coder wants to be real cool

include windows.inc
include wincodec.inc     ; add Windows Core -> WIC
include MasmBasic.inc    ; add MasmBasic Framework. (By jj2007 @ https://masm32.com/board/index.php?topic=94.0 )


Are we going to do this? I,am in, who else is in.

I think I'll start tomorrow.

[HSE]

I know nothing about Watcom.

Is some effort to ignore Japheth work.

Indeed, talk is about JWasm family, wich is far more than rustic Watcom assembler.

[Caché GB]

O.K. HSE, you talk about JWasm if you want. I am only interested in MASM.
So are you going to help or not?

Anyone else going to put some effort in?

[HSE]

I am only interested in MASM.
So are you going to help or not?

Some macros are waiting test and eventually correction/improvements, because Hutch was too busy with videos, printing 3D, hardware, bike, drones, politics, etc

minimum problem with invoke macro

Invoke macro reading prototypes

Also Correction in str$ macro

[Caché GB]

Hi HSE

The Macro Engine could be developed as a component of the SDK in parallel with the Include File Base.

include windows.inc
include SDK64MacroEngine.inc  ; add SDK64 Macro Engine

We would need only a small number of Core Macros to help in the constuction of the Include File Base.

So as it stands, the Core components

1. Include File Base
2. Macro Engine
3. Runtime / stactic
4. Frameworks