News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

First screen of installer inaccessible to screen readers.

Started by Quin, May 01, 2025, 09:04:29 AM

Previous topic - Next topic

Vortex

Hi Timo,

Thanks. To generate a SFX archive is easy, a typical approach is :

copy /b SFXstub.exe + archive.7z Installer.exe

TimoVJL

7Zip can make installer from folder, like links #6 message tell.
Just select Create SFX archive
Have to do more tests, if it search setup.exe from archive folder.
May the source be with you

NoCforMe

Quote from: sinsi on May 02, 2025, 03:58:39 PMThe biggest impediment to both 32 and 64 bit SDKs is translating the Windows SDK header files, specifically equates and structures. The API calls are easy, the .lib files have all the definitions.

Yes, certainly in the case of the 64-bit package.
But despite the problems you mentioned, the MASM32 package is in pretty good shape.
It's true that there's stuff missing from the include files, as I've discovered over the years through my own programming. I've actually collected a good number of missing items myself and put them in my own files. Sure, it would be nice to bring it up to date at some point.
But it's still a very usable tool for programming as-is.
Can't say the same for the 64-bit package, but since I don't use it, I leave that to others.
Assembly language programming should be fun. That's why I do it.

adeyblue

Quote from: sinsi on May 02, 2025, 03:58:39 PMThe biggest impediment to both 32 and 64 bit SDKs is translating the Windows SDK header files, specifically equates and structures. The API calls are easy, the .lib files have all the definitions.
You don't have to do this now. MS publish a C# dll that contains the SDK functions, types, constants etc as metadata you can parse. The point being that C# has built-in support for examining net code with reflection so you can use the normal C# functions to parse out the SDK bits instead of having to build half a custom C++ compiler.

The good news is that I've already done most of the hard work parsing it to produce modern headers/lib package for FreeBasic and, since parsing it is language agnostic, producing an inc/lib set for different languages is in theory as simple as just changing FileOutput.cs to write out what structs, functions, enums, interfaces etc look like in your language.
The bad news is:
- Well, it's written in C#, so you have to know C# to modify it. I use fasm not masm and I don't use asm enough to justify spending the time on it
- The organisation isn't like the SDK. Instead of things like winnt.h or winuser.h, things are in arbitrary namespaces like ui.windowsandmessaging and media.audio.directsound. Of course, if you're writing the output files you can put things in whatever files you want, but that's extra organising you'd need to organise.

Most of the complexity in FileOutput.cs is because FreeBasic is like C and you can't use a type before it is defined and things are spread out over 300+ namespaces, so work goes into checking if this thing needs to be forward declared or if this other header needs to be included or not first. If an asm generator made all params and members dword or qword, you don't need any of that gubbins and it'd be much simpler

NoCforMe

That's nice, I'm sure, but it sounds like a fair amount of work to adapt it to the MASM32 package.

We need a solution that's more native to MASM, not cobbled together out of a C# DLL plus designed for a non-MASM assembler.
Assembly language programming should be fun. That's why I do it.