Have you ever seen the "invalid character in xyz.inc" bug? I see it every 3rd or 4th time I try to build a snippet with ML64.
But that one is harmless, you just hit the build all button again, and it works. Or it complains about missing angle brackets, but again, hitting build again usually helps :badgrin:
Here is one that was more difficult to chase down. The snippet builds without any includes, because I managed to isolate the Windows.inc struct that causes the crash:MAPI_DIM equ 1
MAPINAMEID STRUCT
lpguid QWORD ?
ulKind dd ?
union Kind
lID dd ?
lpwstrName QWORD ?
ends
MAPINAMEID ENDS
SMAPIFormProp STRUCT
ulFlags dd ?
nPropType dd ?
nmid MAPINAMEID <>
pszDisplayName QWORD ?
nSpecialType dd ?
union u
struct sl
nmidIdx MAPINAMEID <>
cfpevAvailable dd ?
pfpevAvailable QWORD ?
ends
ends
SMAPIFormProp ENDS
SMAPIFormPropArray STRUCT
cProps dd ?
ulPad dd ?
aFormProp SMAPIFormProp MAPI_DIM dup(<>)
SMAPIFormPropArray ENDS
.code
start proc
ret
start endp
end
Commandline: \masm32\bin\ml64 /c /Zp8 /Fo "NewWin32" tmp_file.asm
"Output":MASM : fatal error A1016: Internal error
Version 10.00.30319.01
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 01332548 (01310000) "C:\masm32\bin\ml64.exe"
NumberParameters = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 005F0053
CONTEXT:
Eax = 01358624 Esp = 002EEFC8
Ebx = 002EF174 Ebp = 002EF308
Ecx = 008A8313 Esi = 005F0053
Edx = 00000001 Edi = 002EEFE4
Eip = 01332548 EFlags = 00010206
SegCs = 00000023 SegDs = 0000002B
SegSs = 0000002B SegEs = 0000002B
SegFs = 00000053 SegGs = 0000002B
Dr0 = 00000000 Dr3 = 00000000
Dr1 = 00000000 Dr6 = 00000000
Dr2 = 00000000 Dr7 = 00000000
Microsoft (R) Macro Assembler (x64) Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Of course, it builds fine with JWasm, HJWasm and AsmC.
It also builds fine with ML64 if you don't use the -Zp8 switch, but that has other dire consequences :(
Another workaround: Comment out the nmidIdx MAPINAMEID <> line below the union u. Your code will not run with that structure, of course, but at least it will build with ML64 8)
I think there's a bug on project misconception about ml64 and ml32. When they release "ends" they forgot that this means or a structure or a section ends. How can solve this ambiguous question?
If you write code with labels using latin names like "ção" ml64 report more errors than exist.
I'm still waiting for an assembler that shows exactly where error ocurred, not proximity.
:biggrin:
All you have told us so far is you don't understand how to write in ML64. ML64 came before the Watcom forks and the Watcom forks are not ML64 compatible so you can reasonably expect that your Watcom code will not work correctly in ML64.
It is a foolish assumption to think that I will fall into the loving arms of a pile of "Open Sauce" bludgers who won't get off their arse and actually do the work to support Branislav and John.
As far as me using ML64, I already have up and going,
console executables
UI executables
Dynamic link libraries
Dialog applications
Static libraries
Individual object modules
A reliable prologue/epilogue
over 100 macros
over 50 library modules
Fortunately ML64 is not crippled with lack of support in that Vasily's original work did most of the early heavy lifting and it has been the base for further extending support for ML64, it already has a reasonably reliable main include file and VERY reliable libraries and matching INC files. Should we hold our breath waiting for the bludgers to provide the same for the Watcom forks ?
Maybe it works like that, In the latter are the same, but it works
Quote
TmpStruct struct
union u
struct sl
nmidIdx MAPINAMEID <>
cfpevAvailable dd ?
pfpevAvailable QWORD ?
ends
ends
TmpStruct ends
SMAPIFormProp STRUCT
ulFlags dd ?
nPropType dd ?
nmid MAPINAMEID <>
pszDisplayName QWORD ?
nSpecialType dd ?
TmpStruct <>
SMAPIFormProp ENDS
Quote from: hutch-- on September 17, 2016, 08:44:53 AMAll you have told us so far is you don't understand how to write in ML64.
The code that makes ML64 choke was written by Steve Hutchesson, see \Masm32\include\winextra.inc, line 4917.
:biggrin:
I wonder if you have forgotten that it was written for ML.EXE, not ML64.EXE. Neither ML.EXE nor the Watcom forks are ML64 compatible, why should your includes work when they are written for other incompatible assembler ? You may have some axe to grind about ML64 but it is distributed in its millions in VC and similar MS packages.
If I was interested in only the past, I would stick to MASM32 as it does what is needed but I am only interested in 64 bit in the future, long mode 64 bit with the linker option /LARGEADDRESSAWARE. Without this I would only write 32 bit code.
You are flogging a dead horse trying to convert me to the Watcom forks, you may have been committed to JWASM and the later forks but I have always written in MASM. I support Nidud, Branislav and John because they are hard workers and do good work but nobody leverages me to their view and I will never support "Open Sauce", they can get off their arse and do some work to provide the working support for the Watcom forks.
Everything has its advantage, with ML64, it came unconfigured so it meant you had to learn Win64 to get it going. As before,
console executables
UI executables
Dynamic link libraries
Dialog applications
Static libraries
Individual object modules
A reliable prologue/epilogue
over 100 macros
over 50 library modules
And growing by the day. :badgrin:
Quote from: hutch-- on September 17, 2016, 12:39:05 PMI wonder if you have forgotten that it was written for ML.EXE, not ML64.EXE. Neither ML.EXE nor the Watcom forks are ML64 compatible, why should your includes work when they are written for other incompatible assembler ?
That's right, code written for the Watcom forks will not be ML64 compatible (such code may contain strange things like invoke, .if eax>99, etc). However, in contrast to ML64, the Watcom forks
are Masm32 compatible :biggrin:
Yeah,
It really cripppling to have an "invoke" that has native text support built into it, a ".switch" system based off Greg Falen's original macro and Vasily's .IF notation and its all under user control. :P
Quote from: hutch-- on September 17, 2016, 01:07:21 PMan "invoke" that has native text support built into it
Wow, same as your old rv() macro :t Does it validate parameters, too, like the old ML 6.14 that ships with Masm32?
Btw Vasily's .IF notation seems to work only partially; when testing with your dialog example (http://masm32.com/board/index.php?topic=5604.0),
.if eax
nop
.endifworks fine, but
.if eax>ecx
nop
.endifgenerates a weird
error A2006:undefined symbol : eaxecx ::)
Do we all have to relearn MASM syntax to become "ML64-compatible"?
Last but not least:
Quote from: hutch-- on September 17, 2016, 08:44:53 AMIt is a foolish assumption to think that I will fall into the loving arms of a pile of "Open Sauce" bludgers
Since you are the expert, can you explain, in a nutshell, what is the difference between using ML64 and the Watcom forks? I.e. when selling a project assembled with
a) ML64: Microsoft grants it for free and does not ask for any royalties
b) Mr Watcom (or Habran, Johnsa, Nidud, Japheth, ...) will charge you hefty fees ::)
If you cannot read Vasily's instructions, perhaps you should take up a visual garbage generator.
Operator Meaning
== Equal
{} Not equal
} Greater than
}= Greater than or equal to
{ Less than
{= Less than or equal to
& Bit test (format: expression & bitnumber)
~ Logical NOT
| Bit test
&& Logical AND
|| Logical OR
CARRY? Carry bit set
OVERFLOW? Overflow bit set
PARITY? Parity bit set
SIGN? Sign bit set
ZERO? Zero bit set
CARRY?|ZERO? ìåíüíå èëè ðàâíî
~(CARRY?|ZERO?) áîëüøå
äëÿ ñðàâíåíèÿ ÷èñåë ñî çíàêîì
~ZERO?&(SIGN?==OVERFLOW?) áîëüøå(greate than)
SIGN?==OVERFLOW? áîëüøå èëè ðàâíî(greate than or equal)
SIGN?{}OVERFLOW? ìåíüøå(less than)
ZERO?|(SIGN?{}OVERFLOW?) ìåíüøå èëè ðàâíî(less than or equal)
Quote from: jj2007 on September 17, 2016, 06:20:36 PM
Do we all have to relearn MASM syntax to become "ML64-compatible"?
Ouch, I was scared of your answer, and there it is :(
Quote from: hutch-- on September 17, 2016, 06:41:12 PM
}= Greater than or equal to
.if eax>=ecx
.IF eax }= ecx
I hope it won't trigger reactions from the FASM & NASM communities 8)
:biggrin:
I am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64 when they should have anticipated back in 1990 when ML.EXE was released that it had become the new Bible for assembler language programmers. Now as you might expect, ML64 does not conform to the ALGOL specification of the 1970s either, was COBOL too radical ?
Having survived the shift from 16 bit DOS to 16 bit Windows, then to 32 bit Windows and more recently 64 bit Windows, each brave new world dumps you with a pile of crappy tools, lousy documentation and a lot of work if you are not willing to either stay with the old stuff OR get off your arse and do enough work to get the new stuff going. I have made my point long ago that "Open Sauce" is a nasty possessive licencing system that acts like a cancer on individual effort and where its adherents bludg anything they can steal and never give anything back except they PHUKING licence.
You may be saddled with an impossible task of trying to handle cross compatibility between different assemblers but it is a task of your own choosing, design a support system for the Watcom forks that actually works and see the bludgers white ant it because they were too PHUKING lazy to do it themselves. Some of the tools I am producing at the moment will be useful to folks who do get off their arse and develop a support system but there will be very few of them who bother, most want someone else to do it for them.
Quote from: hutch-- on September 17, 2016, 07:03:41 PMI am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64
No, the Redmond guys are rubbing their eyes in disbelief :eusa_boohoo:
They had taken the heroic decision to drop assembler as a tool for human coders, no invoke, no HLL, just plain mnemonics for some old-fashioned compilers who needed that as an input. And then comes that Australian Don Quichote who wants to convince the rest of the programming community that
if arg1 }= arg2 looks better than
if arg1 >= arg2 ...
Redmond lurkers, c'mon, one of you should register and give us feedback on how the situation is right now in the Crisis Room :icon14:
It's no big deal to learn that new syntax. The problem is re-using old code. Converting 32 bit code - either ML, JWasm, or asmc - to 64 is not bad with HJWasm or asmc. But it's much harder to go to ML64. Sure, you "just" change ">" to "}" - although you can't do a global change, must consider each one individually. No big deal. But how many such are there? The worst part is stripping out perfectly good code, for no good reason. My favorite example is "ASSUME". You can't merely change those specific statements, but must make a lot of little associated changes. If there were a good reason for it, you were buying some new capability this way, it would be Ok. But the opposite is true.
Similar problem arises for those of us who continue to use both 32 and 64. With HJWasm, or asmc, it's very easy once you get used to it. Most of my code works with either 32 or 64, leveraging a few obvious "IF" statements. Sometimes code makes sense only for 64, as when making extensive use of the extra registers, but that's rare. And of course you use the same assembler for both. With ML you need both old 32-bit assembler and new ML64, plus the right auxiliary files; and the syntax is quite different. Forget about "one-size-fits-all". And, BTW, every time you upgrade to the latest ML64, you're going to need a new set of auxiliary files.
If there were no alternative to ML, it would be annoying but one would take it in stride. But (I can tell you this from experience) the worst part of using ML64 is that half your time is spent asking yourself: "Why don't I just use HJWasm (or asmc)? Why am I wasting my time with this? I hate Bill Gates ..." and similar unproductive thoughts.
Oh well, hutch, I hope it works out well for you and other ML64 enthusiasts. If you can avoid the above-mentioned unproductive thoughts, because you feel there's a good reason for using it, it shouldn't be too bad. Maybe time will prove you right. Maybe Bill will create an effective anti-HJWasm-and-asmc virus.
BTW the worst part of HJWasm and asmc is having to write out "HJWasm and asmc" instead of simply "ML64".
As some programmers can choose tools they use, bare C compiler is handy as 'universal assembler'.
It can be used without crt etc...
It can do code optimization too.
Even MS developed it in it's last version (2015).
Sure, C is a good alternative. But asm is much easier to use.
:biggrin:
> And then comes that Australian Don Quichote who wants to convince the rest of the programming community that if arg1 }= arg2 looks better than if arg1 >= arg2 ...
Nah, real men[tm] do it with mnemonics.
mov r10, arg1
cmp r10, arg2
je label
You know how it is, you can tell the men from the boys by the paper they use, (sheet of #0000 [very coarse] sandpaper) hung in the loo. :P
It must be tough when you cannot rely on Microsoft 1990 design any longer to hold your hot little hand and you have to deal with those dirty INTEL mnemonics. Someone would think you were trying to write in assembler when you deal with mnemonics directly. :biggrin:
Quote from: hutch-- on September 17, 2016, 07:57:22 PMNah, real men[tm] do it with mnemonics.
When searching the old forum for
laughing stock (http://www.masmforum.com/board/index.php?action=search;advanced), I found these two valuable references:
Its well and good to talk about coding in bare mnemonics and most of the old fellas have done so for years but there is more to programming than the barest code possible, sheer complexity which is often not all that speed related is better handled with properly tailored macros as it improves the logic and readability of the code. (http://www.masmforum.com/board/index.php?topic=10533.msg77393#msg77393)
they can always write the code manually but that type of code was what made assembler the laughing stock of programming 10 years ago (http://www.masmforum.com/board/index.php?topic=10533.msg77402#msg77402) :t
Welcome to the brave new world where everything has changed. You have nothing to convince me about, Win64 is not Win32. Porting one to another is a pipe dream that you have committed yourself to without knowing all of the problems.
Since it was your complaint that Vasily does not comply with Microsoft design with "{=", if you don't like his notation, use mnemonics.
Try using SetWindowLong() in Win64. It has changed to SetWindowLongPtr().
Sooner or later you will have to wean yourself off the Microsoft 1990 teat and start writing assembler.
As before, this is already done using that poor crippled non visual garbage disgusting Microsoft assembler ML64. :biggrin:
console executables
UI executables
Dynamic link libraries
Dialog applications
Static libraries
Individual object modules
A reliable prologue/epilogue
over 100 macros
over 50 library modules
And growing by the day.
Quote from: hutch-- on September 17, 2016, 07:57:22 PM
> And then comes that Australian Don Quichote who wants to convince the rest of the programming community that if arg1 }= arg2 looks better than if arg1 >= arg2 ...
Nah, real men[tm] do it with mnemonics.
mov r10, arg1
cmp r10, arg2
jge label
Frankly I prefer the mnemonics approach myself. But it's the principle of the thing. Why change what you're used to, when you don't have to? Also, that curly bracket
looks wrong.
deleted
nidud,
Looks good. :t
Here is yet another piece of this terrible toothless crippleware produced with ML64. It is an interface test for a vertical toolbar. No source as it cannot be built without the latest macros and libraries which will come later as I am still writing a lot more new stuff. I am hoping to get in front of the UI stuff so I can do some work on high speed algos but I have not got there yet.
Quote from: hutch-- on September 18, 2016, 01:38:48 AM
Here is yet another piece of this terrible toothless crippleware produced with ML64.
I definitely can't agree with characterizing it as either "terrible" or "toothless". The differences between ML64 and Asmc, or HJWasm, are not that huge. You can do all the same things with any assembler. It's just a bit harder, more annoying, slower, with ML64. Certainly, if only that were available, I'd use it, and get the same functionality. But why bother, when you have better alternatives? - No need to answer that! I know: "Open Source".
I would be interested to see if Japheth's JWASM could be used with the libraries and includes that I already have using the macros I have done but it would still require some of Vasily's macros and I gather that JWASM may not run them properly.
Quote from: hutch-- on September 18, 2016, 08:52:21 AMit would still require some of Vasily's macros
It would require disabling the
.if, invoke etc macros with e.g. IFIDNI @Assembler, <ML> then .if macro ...
Perhaps like this:
IFIDNI @Assembler, <ML>
include VasilysMacros4ML64.inc ; invoke, if else endif, repeat ... until, while ... wend, switch .. case .. endsw
ENDIF
include Macros4allAssemblers.incMacro compatibility per se is no longer a problem. All MasmBasic macros work with all our assemblers. Occasionally, I had to tweak them a little bit to make them work with ML and the Watcom family, but there is not a single one that needs conditional assembly.
I'd expect a handful of minor issues. To get it working might take somewhere between a few minutes to a few hours - you know how these things can often be more trouble than expected, what with one thing and another.
Is it truly the dawning of the age of assemblyius(Aquarius) ,man I did not want to go back to my misspent youth and all those cute blotter things.
ML64 may indeed be the Necronomicon of the all new,all so much more tweeked assembler of the digital black hole into the age of Jimmy Netron
This is Jimmy BTW.
(http://static.comicvine.com/uploads/original/14/146951/3182425-6551699399-tumbl.jpg)
Looks a bit like Zen I think...
He sure does look like Zen! And the other guy in the red shirt reminds me of hutch
Quote from: hutch-- on September 17, 2016, 07:03:41 PM
I am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64
Just found a very interesting exchange of views, over 11 years ago, between
Microsoft (Kang Su Gatlin, Visual C++ Program Manager) and some members of this forum titled MASM on x64 (http://www.masmforum.com/board/index.php?topic=908.0):
M$: how important is "INVOKE" for x64 MASM? ... Would you rank INVOKE as more or less important than the high-level control flow directives such as .WHILE, .IF, etc...?
Randy Hyde: The *vast* majority of MASM32 projects I've ever seen certainly use both.
Eugen: I am using MASM for writing fairly complex commercial applications (mainly shareware games) and i consider critical to be able to use both invoke and if/else HLL constructs.
hutch--: a properly designed INVOKE style syntax becomes critical to this range of users. Particularly for C/C++ programmers who are used to prototyping and the reliability of size and parameter count checking, bare mnemonics are very unpalatable to them.
Tedd: rough guesses on what I personally use, though I dare say others are similar.. invoke - LOTS, proc/endproc - lots, .IF/.ELSEIF/.ELSE - very often
GregL: PROTO / INVOKE are very important to me, as well as .IF. .WHILE and .LOOP would be next in importance.
BogdanOntanu: I will never use an assembler that has no invoke or extended call syntax and .IF .ELSEIF .ELSE .ENDIF constructs included in the assembler.
hutch--: In terms of priority of pseudo high level constructions, I would tend to place them in this order.
1. INVOKE Critical for C/C++ programmer who are used to prototyping and who have little chance of writing bare mnemonic code.
2. .IF block syntax for sequential conditional testing. Nearly as critical for reliable higher level code.
3. .WHILE / .REPEAT loop code syntax. Useful but can generally be replaced with manual loop code.
M$: I'd like to thank EVERYONE for their feedback.
> I am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64
And you got your response with ML64.
I did make the point with Kang Su Gatlin that ML.EXE should not be combined with a 64 bit version. ML workes well in 32 bit, no reason to mess it up with another OS environment. I would not have complained if they had have spent the development time with call automation and high level control flow directives but I can live without the and with Vasily's macros and my own, I don't have to.
msgloop proc
LOCAL msg :MSG
LOCAL pmsg :QWORD
mov pmsg, ptr$(msg) ; get the msg structure address
jmp gmsg ; jump directly to GetMessage()
mloop:
.switch msg.message
.case WM_KEYUP
.switch msg.wParam
.case VK_F1
invoke SendMessage,hWnd,WM_COMMAND,300,0
.endsw
.endsw
invoke TranslateMessage,pmsg
invoke DispatchMessage,pmsg
gmsg:
test rax, function(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
jnz mloop
ret
msgloop endp
Windows.inc, line 24748:
COMP_ELEM_ALL equ (COMP_ELEM_TYPE+COMP_ELEM_CHECKED+COMP_ELEM_DIRTY+ ... +COMP_ELEM_FRIENDLYNAME)
Works fine with all 64-bit assemblers except the latest Visual Studio Community version named Microsoft (R) Macro Assembler (x64) Version 14.00.24210.0, which produces a garbled error message:*** Assemble using \masm32\bin\ml64 /c /Zp8 /Zp8 /Fo "test64" tmp_file.asm ***
Assembling: tmp_file.asm
** 64-bit assembly **
***********
ASCII build
***********
\Masm32\MasmBasic\Res\DualWin.inc(24748)ified size
\Masm32\MasmBasic\Res\DualWin.inc(24748) : error A2042:statement tMicrosoft (R) Macro Assembler (x64) Version 14.00.24210.0
With COMP_ELEM_ALL equ etc commented out, it builds fine, but it takes almost 14 seconds instead of 0.4 secs with the older version 10.0 (HJWasm32 and AsmC: 0.3 secs) 8)
The version of "windows.inc" in the MASM32 SDK is designed for ML.EXE, not ML64.EXE. It may be OK with the Watcom forks but neither ML or the forks are ML64 compatible. You can get errors by using the wrong data for a tool any old time. Fortunately ML64 is not crippled with these limitations and simply uses its own compatible includes and libraries. If I want to write 32 bit software I use the MASM32 SDK as its a mature and reliable system with years of practice.
RE: Anyone using the MASM32 version of "windows.inc" has probably used it because they did not have to write it in the first place, it is order dependent and took a very long time to get it working properly. I am still repairing Vasily's win64.inc that made extensive use on the 32 bit version of windows.inc with complete sections of equates copied from the 32 bit version and have just untangled a mess of nested typedefs so that the data types are consistent and understandable and while I have added support for both common controls and dialogs, there is a lot more that needs to be done with structures.
The technique for maintaining windows.inc is a fully automated system that is constructed from about 50 files so its far easier to isolate individual sections if changes are needed. For anyone who wants to complain about the odd glitch in windows.inc, they can always get off their arse and write their own, its a messy and time consuming thankless task that few will undertake.
Quote from: hutch-- on October 05, 2016, 12:15:25 PM
The version of "windows.inc" in the MASM32 SDK is designed for ML.EXE, not ML64.EXE. It may be OK with the Watcom forks but neither ML or the forks are ML64 compatible.
Truth is that ML64 is not compatible with ML32 and the Watcom forks :P