Hello friends.
I know we still cannot solve the administrative and financial problems of our beloved forum. But I want to suggest an important thing.
Dear friends in my opinion we should "also" open a MASM-SDK organization on github (https://github.com/MASM-SDK)(or gitlab (https://gitlab.com/masm-sdk)). Then we should put MASM32 SDK and MASM64 SDK to there. We should license them if they do not have licensed by hutch--. So that we can easily improve, bug fix, typo fix and release new versions of SDK's. People can easily contribute and issue problems. We can hold our sdk's more updated. And we don't have to be afraid that they will disappear suddenly.
Until now, hutch-- himself tracked issues, fixed typos/bugs and released new versions. From now on we should do this on Github(or gitlab)
After SDK's, we should put important or community driven projects and code sniplets(maybe?) to our our code repositories. We can put member projects(You know; some member projects are full-fledged projects).
P.S. I am very aware that most (total?) of the macros for masm64-sdk has written by vasily. We have to ask him first. But I do not have direct communication with him.
BTW folks, those are just thought. I love assembly programming. And I really do not want to lost anything on this forum. I saw many forums and portals has gone in one night! Using a code repository solves many problems.
What do you think? I can't wait to hear your thoughts too.
Cya
Good idea ! :thumbsup:
Quote from: bluedevil on June 09, 2023, 07:59:19 AM
P.S. I am very aware that most (total?) of the macros for masm64-sdk has written by vasily. We have to ask him first. But I do not have direct communication with him.
Just part of macros were writed by Vasily. Curiously... those macros are in file Vasily.inc :biggrin:
Quote from: HSE on June 13, 2023, 06:09:54 AM
Quote from: bluedevil on June 09, 2023, 07:59:19 AM
P.S. I am very aware that most (total?) of the macros for masm64-sdk has written by vasily. We have to ask him first. But I do not have direct communication with him.
Just part of macros were writed by Vasily. Curiously... those macros are in file Vasily.inc :biggrin:
How can I reach Vasily? Or do I need to reach him If we agreed on publishing MASM SDK's on Github(lab)
What you CANNOT do with the MASM32 SDK.
1. The MASM32 SDK is not an item of trade or commerce. It cannot be either purchased or sold.
2. The MASM32 SDK cannot be re-licenced or made subordinate to any other form of licence.
3. None of its components or source code are redistributable.
4. You cannot use the MASM32 SDK to write software for Non-Microsoft Operating Systems.
5. You cannot use the MASM32 SDK to write any form of illegal software.
6. The SDK does not authorise the use of the Microsoft Trademark in your software or claims that your software is certified by Microsoft.
That means no GitHub for MASM32 SDK :rolleyes:
Quote from: HSE on June 13, 2023, 07:08:01 AM
3. None of its components or source code are redistributable.
So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
Sooo, what can we do?
So far, you can improve, develop, bugfix or typofix MASM64 SDK here.
Quote from: HSE on June 13, 2023, 07:33:26 AM
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
Sooo, what can we do?
So far, you can improve, develop, bugfix or typofix MASM64 SDK here.
Right. A code repository is an absolute overkill imho.
Quote from: HSE on June 13, 2023, 07:33:26 AM
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
Sooo, what can we do?
So far, you can improve, develop, bugfix or typofix MASM64 SDK here.
I got it, thank you =)
bluedevil,
did you receive my e-letter?
Masm64 sdk,who should be in charge of continue develop it ?
Masm32 sdk has different coders contributed to examples
If anyone want to contribute with masm64 examples,who will decide if they get included in masm64 sdk ?
Group effort easier can produce more than a single coder
I hope for keep on develop it
Quote from: Mikl__ on June 13, 2023, 10:45:03 AM
bluedevil,
did you receive my e-letter?
Thank you @Mikl__ I've got it.
Quote from: daydreamer on June 13, 2023, 04:26:45 PM
Masm64 sdk,who should be in charge of continue develop it ?
Masm32 sdk has different coders contributed to examples
If anyone want to contribute with masm64 examples,who will decide if they get included in masm64 sdk ?
Group effort easier can produce more than a single coder
I hope for keep on develop it
The Masm32 SDK was indeed a joint effort, although Hutch contributed most of it, if I remember correctly.
Same applies to MasmBasic: many of its routines have been thoroughly tested in The Laboratory.
(There are other packages like GoAsm, ObjAsm that I don't know well - I hope their authors see this and comment.)
So in these two cases there was one maintainer and several contributors, loosely organised. That worked fine, and there was never a need for a GitHub-style repository.
Now the Masm
64 SDK was exclusively Hutch' work (building on some macros by Vasily - but that was a minor part).
The situation is a lot different, also because there were three different approaches to Masm64: Hutch, UAsm (http://masm32.com/board/index.php?topic=7301.0) and my dual assembly (http://masm32.com/board/index.php?topic=9266.0).
Masm 64-bit coding was, and is, a bit messy. Personally, I don't have stakes in 64-bit Assembly, as I am so old that I will not see the end of 32-bit coding. Who wants to take the lead?
Mikl, what about you?
As to "Group effort easier", dear daydreamer, I would be happy to see
any new code in this forum...
Quote from: jj2007 on June 13, 2023, 07:51:44 PM
I don't have stakes in 64-bit Assembly, as I am so old that I will not see the end of 32-bit coding.
Are you sure about that JJ.
Intel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained
https://www.youtube.com/watch?v=KSagW5gmPo4
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Ciao, Jochen!
Of course, I would like to make every effort to create a masm64 package, but the project leader from me is so-so, I'm not even a professional programmer, I'm just an engineer, assembler is just my hobby. I'm happy to join the group work on the project, whatever that means... (https://wasm.in/styles/smiles_s/friends.gif)
Quote from: Caché GB on June 13, 2023, 08:21:13 PM
Intel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained
For me, 32 bit will last at least the rest of my life. I have zero intention of buying any new computer. I have two older models that run 32 bit Windows 7 Pro and they both run very well. One that I use every day, the other which is exactly the same - I keep as a backup 'just-in-case'. They also can both run 64 bit, but only up to Windows 10. Windows 11 needs a more up-to-date TPM 'Trusted Platform Module' so thankfully I don't run Windows 11. Windows 10 is bad enough and I only use it when necessary to look at 64 bit programs made by others.
Mikl__ seems a good choice for continuing development of the 64 bit SDK. I am sure there will be others who may want to pitch in and help with that effort.
Quote from: Caché GB on June 13, 2023, 08:21:13 PM
Quote from: jj2007 on June 13, 2023, 07:51:44 PM
I don't have stakes in 64-bit Assembly, as I am so old that I will not see the end of 32-bit coding.
Are you sure about that JJ.
Yes, absolutely. What most people don't realise:
- Going from 16-bit to 32-bit was a fantastic improvement: 5 times faster, 2GB address space instead of 640kB, flat mode.
- Going from 32-bit to 64-bit was... what? Same speed (often slower), more bloat, and an address space that almost nobody needs.
64-bit was forced down our throats by hardware vendors. Users, however, will stick to their 32-bit applications as long as they can.
QuoteIntel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained
https://www.youtube.com/watch?v=KSagW5gmPo4
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Announcements are not action. They wouldn't be able to see such cpus.
Quote
Yes, absolutely. What most people don't realise:
- Going from 16-bit to 32-bit was a fantastic improvement: 5 times faster, 2GB address space instead of 640kB, flat mode.
- Going from 32-bit to 64-bit was... what? Same speed (often slower), more bloat, and an address space that almost nobody needs.
64bit MASM uses
fastcall calling convention instead of
stdcall or
c or other oldies. First 4 parameters use registers (rcx,rdx,r8,r9) instead of stack memory for parameters. Should be faster with not so much memory access overhead. I know they have done much for C++ coders to use newer instruction sets without using ASM. And 32bit platform allows only 4 GB of memory for a process, not like I'm going over it soon, but maybe someday I need that too.
We have to preserve what Hutch made, it's quite a big package, but there aint everything I needed, so it under developement I guess.
And last, many of you have contributed to both MASM32/64 packages. I have to say
thank you for what you have done. I like your code postings very much too. As a ASM "beginner" :eusa_dance:
BAD POSTING :dazzled:
I'll start, and the rest will catch up. I have only one question so far - where to write about SDK64 in the MASM64 SDK section or in Mikl__'s ml64 examples section? I don't know (and will never know) Hutch's plans for SDK64 so I'll start from scratch and gradually add examples that Steve has already written...
Hi Mikl, I had hoped you would volunteer for the Masm64 SDK :thup:
You have this wonderful 64-bit examples thread, which unfortunately not many people (including myself) have commented on. That's an excellent start, and I am sure Hutch would be happy to see you in charge of Masm64 :thumbsup:
Hi zedd151
I hope you are doing well. Thank you so much for replying to my post. Not many members do.
It's probably my dry-wit humour. I shoud put a trigger warning before I post.
I get what you saying. That been said, obsolescence can bite when least expected as every
corporation builds it into there products.
Hi JJ
We've had this discussion before.
http://masm32.com/board/index.php?topic=7238
That time I lost. This time I'm going for a draw.
So I hope you live long, see the end of 32-bit, and prosper - Vulcan salute.
Hi C3
WARNING!!! - Dry humour to follow.
At the risk of you becoming C4, who's posting was bad?
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?
We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.
Food for thought.
That is a violation of license terms. MASM32 is free source, not open source. Explicitly, you can not make "open" things.
Because you don't declare a license, what you makes is not free nor open, is just your thing, and anybody using that is subject of legal enforcement.
Obviously, if you are violating licences you are subject of that problems first.
The Masm32 Project License can be found in the masm32 directory:
<drive letter:>\masm32\licence\licence.htm
Quote from: hutch-- on June 27, 2018, 02:57:39 PM
I doubt we will see the end of 32 bit any time soon.
@Caché GB :smiley:
Quote from: fearless on June 14, 2023, 10:10:18 AM
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?
We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.
Food for thought.
Indeed, but let's tread carefully with Hutch' legacy. He would rotate in his grave if we came up with an open source version of the Masm* library...
Quote from: jj2007 on June 14, 2023, 01:01:18 PM
Quote from: HSE on June 14, 2023, 08:51:07 AMAnyway, more updated versions can be downloaded from Microsoft, exactly what we make with 64 bits tools.
That would be prohibitive for a n00b who wants to "have a quick look". So we better clarify whether the old license is valid.
There is UAsm, of course, but Hutch had his reservations, as we all know...
A similar problem. Plus, if "anyone can create similar named functions to help others use x86 or x64 assembler code" (fearless), there is a risk to end up with a dozen competing Masm64 versions (I have my own one, of course, but don't use it - see Dynamic vs static linking (http://masm32.com/board/index.php?topic=6135.0), or search for JBasic).
This is a delicate discussion. It is relatively easy for the Masm32 library: we can just keep the original archive, and optionally offer an improved version with a more straightforward installer, UAsm instead of the March 1999 ml.exe, and a few bug fixes in the Windows.inc file.
For Masm64, it gets tricky precisely because Hutch...
a) liked Microsoft MASM and therefore chose Vasily's
.if eax { ecx macros;
b) wrote a nice library
...while others...
a) preferred the
.if eax < ecx syntax and therefore used UAsm (or AsmC);
b) but didn't write an equivalent library.
Now the last point might be unfair to fearless, but that points to another problem: I had never heard about it. GitHub is full of projects that have no community such as this
forum. Maybe fearless' library is a mature project, and a serious alternative to Hutch' Masm64?
You see why it's a delicate question? We need to discuss that patiently - there is no hurry. The extreme options are 1. an eternally frozen version of Masm* ("we cannot improve"), 2. an awful mess of competing versions that makes everything fall apart.
I want to port/ improve simd with help of 16 simd registers in 64 bit
It's the right way to keep cool and continue coding
Register starved 32 bit or lots of push/ pops in code, 64 bit has 16 gp regs
SIMT easier to have lots of memory hungry threads/cores in 64bit
Quote from: fearless on June 14, 2023, 10:10:18 AM
Quote from: bluedevil on June 13, 2023, 07:18:38 AM
So we cannot improve, develop, bugfix or typofix MASM64 SDK through a code repository right? Sooo, what can we do?
We can make an open source version of the masm32 library and/or the masm64 library. I started some of that with a 64 bit version port of the masm32 library a while ago: https://github.com/mrfearless/libraries/tree/master/Masm64 - but anyone can create similar named functions to help others use x86 or x64 assembler code. The include files for an open source version could easily start with the WinInc files and progress from there. Ideally an automated solution to convert existing win32 header files to asm include would be the end goal - some attempts have been looked at and tried a while ago by Biterider using the microsoft metadata for windows header files located at github.
Food for thought.
Even though this might not be accepted by the community but I share the same thoughts with fearless :thup: . This is the more logical, more sustainable and more "community-way" for developing an assembly SDK. Both MASM32 SDK and MASM64 SDK are hutch--'s personal projects. He even created a special license for his project. He is not with us bu we "the community" is here. Some of us are more active some of us are less active.
Quote from: HSE on June 14, 2023, 11:23:07 AM
That is a violation of license terms. MASM32 is free source, not open source. Explicitly, you can not make "open" things.
Because you don't declare a license, what you makes is not free nor open, is just your thing, and anybody using that is subject of legal enforcement.
Obviously, if you are violating licences you are subject of that problems first.
I thinks fearless wants to say creating a very new open source project, not to open source MASM64 SDK.
Still, I am all OK community's decision!
Quote from: bluedevil on June 14, 2023, 09:24:40 PMThis is the more logical, more sustainable and more "community-way" for developing an assembly SDK
MASM is competing with FASM, NASM and TASM (https://stackoverflow.com/questions/61857760/difference-between-nasm-tasm-masm) (UASM is 100% MASM-compatible, so doesn't count here)
There are already at least 3 competing Masm64 packages.
How many users do (in alphabetical order) GoAsm, EasyCode, HLA, ObjAsm, PoAsm, RosAsm, SmplMath, SolAsm have?
How many users does MasmBasic have? (one)
How many distros are calling themselves "Linux"? (over 600 (https://truelist.co/blog/linux-statistics/#:~:text=Today%2C%20there%20are%20over%20600%20active%20Linux%20distros.,-Another%20500%20are&text=Some%20of%20the%20most%20commonly,Linux%20distribution%20usage%20statistics%20show.)...)
There is exactly
one Masm32 package, and all its examples work fine on Win98...Win11.
How do you define "sustainable"?
Quote from: jj2007 on June 14, 2023, 01:19:14 PM
You see why it's a delicate question? We need to discuss that patiently - there is no hurry. The extreme options are 1. an eternally frozen version of Masm* ("we cannot improve"), 2. an awful mess of competing versions that makes everything fall apart.
Quote from: bluedevil
I thinks fearless wants to say creating a very new open source project, not to open source MASM64 SDK.
Yes, exactly. As the license states "None of its components or source code are redistributable", which means any "MASM" library functions would have to be coded differently and written from scratch, and doesn't have to include the name "Masm", "Masm32" or "Masm64" - could just be called asm.lib or asm86.lib/asm64.lib or whatever.
A compatible recreation of the masm library is all I am suggesting as a possible option.
A new sdk is a different thing, although as I mentioned before using WinInc for the includes could be used as a starting point. Creation of libs can be done with batch files or collated from other sources or using other tools to create them. But a compatible and full sdk is beyond what I was suggesting.
Quote from: fearless on June 14, 2023, 10:44:00 PMusing WinInc for the includes could be used as a starting point.
My question is whether we will be able to tell a n00b "click here to start your first Masm64 project" (that's how Masm32 works - see \Masm32\examples...).
Honestly I don't know. Maybe one day perhaps. I suspect it may require a lot of work to bring the WinInc files up to date and maintain them to even approach something as comprehensive and all inclusive as the current masm32 sdk. An automated solution to convert the ms windows header files to asm includes would be the ideal solution, but as Biterider can attest to, its not an easy task.
Quote from: fearless on June 15, 2023, 12:43:27 AMAn automated solution to convert the ms windows header files to asm includes would be the ideal solution, but as Biterider can attest to, its not an easy task.
I can attest that, too - I invested quite a bit of time into that task, but at a certain point lost the interest in 64-bit code...
Quote from: jj2007 on June 14, 2023, 10:49:47 PM
Quote from: fearless on June 14, 2023, 10:44:00 PMusing WinInc for the includes could be used as a starting point.
My question is whether we will be able to tell a n00b "click here to start your first Masm64 project" (that's how Masm32 works - see \Masm32\examples...).
Masm64 need for "wizard" based on templates done?
Console template and windows template ?
Hi fearless,
Are you referring to these Windows include files ?
https://www.terraspace.co.uk/uasm.html#p8
QuoteWinInc is mostly compatible with the include files supplied with Masm32. The main differences are:
In Masm32 there is one big include, WINDOWS.INC, which contains the Win32 declarations, and a bunch of other includes which contain the function prototypes.
The include files of WinInc match 1:1 the header files contained in MSVC or MS PSDK, with extension .H replaced by .INC of course.
Unlike Masm32 the prototype parameters of the WinInc include files are "typed". They usually have the same type as their C counterparts.
In Masm32 all parameter types are "DWORD". Having typed parameters may be advantageous if the target has to be debugged and the debugger knows how to handle the MASM debug type information.
The few name conflicts are resolved differently. In WinInc, a name which is used in the Win32 API and is also a MASM reserved word (for example, "mask"), is changed by
adding a "_" suffix. In Masm32 the kind of the name modifications isn't consistent.
WinInc includes are more up-to-date than the ones coming with Masm32. All declarations for the Win32 API extensions added to Windows 2000 and Windows XP are there.
For some reason Masm32 doesn't allow to develop Open Source software with it. Furthermore none of its parts are redistributable. WinInc does not have such restrictions, it is Public Domain.
Quote from: Vortex on June 16, 2023, 04:46:58 AM
WinInc is mostly compatible with the include files supplied with Masm32.
Mostly compatible, really? I've tried to get some of the examples to assemble, no luck.
C:\Masm32\WinInc\Samples\WinGUI1\WinGUI1.ASM
***********
ASCII build
***********
\Masm32\include\winextra.inc(22295) : Error A2143: Symbol redefinition: WINVER
\Masm32\include\winextra.inc(22295): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(17): Main line code
Tmp_File.asm(38) : Error A2143: Symbol redefinition: CStr
Tmp_File.asm(51) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(66) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(68) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(69) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(70) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(71) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(74) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(77) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(97) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(103) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(115) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(121) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(140) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(143) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(152) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm(154) : Error A2160: INVOKE requires prototype for procedure
Tmp_File.asm: 157 lines, 1 passes, 65 ms, 0 warnings, 18 errors
*** Assembly error ***
Hi Jochen,
Assuming that the include files are extracted to the folder \masm32\wininc :
G:\masm32>dir \masm32\wininc
04.10.2014 10:55 15282 AccCtrl.inc
16.05.2013 08:07 9575 AclAPI.INC
16.05.2013 08:07 261913 AdoInt.INC
16.05.2013 08:07 63499 ASPTLB.INC
16.05.2013 08:07 4800 BaseTsd.INC
16.05.2013 08:07 1401 CDERR.INC
16.05.2013 08:07 1520 cguid.INC
.
.
.
Build.bat :
\masm32\bin\rc Rsrc.rc
\masm32\bin\ml /c /coff /I\masm32\wininc WinGUI1.asm
\masm32\bin\polink /SUBSYSTEM:WINDOWS /LIBPATH:\masm32\lib WinGUI1.obj Rsrc.res kernel32.lib user32.lib gdi32.lib
Hi Erol,
That worked, thanks a lot :thup: