CrippleWare News

[rrr314159]

Sure, C is a good alternative. But asm is much easier to use.

[hutch--]

 

> 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.

[jj2007]

Nah, real men[tm] do it with mnemonics.

When searching the old forum for laughing stock, 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.

they can always write the code manually but that type of code was what made assembler the laughing stock of programming 10 years ago :t

[hutch--]

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. 

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.

[rrr314159]

> 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.

[nidud]

deleted

[hutch--]

nidud,

Looks good.  :t

[hutch--]

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.

[rrr314159]

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".

[hutch--]

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.

[jj2007]

it 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:

Code: [Select]

IFIDNI @Assembler, <ML>
  include VasilysMacros4ML64.inc   ; invoke, if else endif, repeat ... until, while ... wend, switch .. case .. endsw
ENDIF
include Macros4allAssemblers.inc
Macro 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.

[rrr314159]

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.

[anunitu]

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.


Looks a bit like Zen I think...

[rrr314159]

He sure does look like Zen! And the other guy in the red shirt reminds me of hutch

[jj2007]

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:

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.