Jobs

[hutch--]

I think you are mixing up the toys, 32 bit ML is a successor to ML version 6.0 from 1990, ML64 is a reasonably recent binary and while its rather agricultural for those used to the pseudo high level notation, its a recent tool that does the job that the owner requires. If I get around to writing 64 bit Windows assembler, something I am in no hurry about, ML64 looks fine, I grew up writing assembler code that looked like an assembler dump so it ain't like its anything new.

RE: The articles published on Fravia's site in 1997, they did what I intended, they pointed people interested in asembler to assembler, not the booby prize of cracking crap software or learning how to write keygens. Interestingly enough nobody I know who was writing assembler code back then had a cracking or virus background, you must have hung around in bad company.  :bg

We certainly had plenty of both back in the IRC days when that was the most effective way to support assembler programming but basically the kids into cracking were to lazy to learn to write decent code and the virus gang were a bunch of jerks at best who wrote genuine crap assembler.

[donkey]

RE: The articles published on Fravia's site in 1997, they did what I intended, they pointed people interested in asembler to assembler, not the booby prize of cracking crap software or learning how to write keygens. Interestingly enough nobody I know who was writing assembler code back then had a cracking or virus background, you must have hung around in bad company.  :bg

Yeah, you know me, bad company  :bg Does help in moderating the forum though, not much gets past us  :wink

Anyway this debate can go on and on, hopefully we're still arguing about it for Windows 20. I think we're both stubborn enough to live that long  :bg

[disintx]

and the virus gang were a bunch of jerks at best who wrote genuine crap assembler.

I have to disagree with you there. A lot of the old virus coders were pretty good at assembly and knew some neat tricks.
Of course, the destructive part of their work wasn't cool, but a lot of the good ones didn't release stuff into the wild.

[hutch--]

Edgar,

:bg

disintx,

I would stand by the comment, neat tricks mean obscure techniques to hide malicious code that exploited lousy design at an OS level. Many of the neat tricks were trashed with OS level stack protection and later OS design that randomised stack addresses. Aside from obscure stealth techniques their architecture was trash and the code performance was really poor. The majority of this crap shifted to trojans written in high level languages like C++ where weaknesses in the registry design were exploited instead.

[disintx]

disintx,

I would stand by the comment, neat tricks mean obscure techniques to hide malicious code that exploited lousy design at an OS level. Many of the neat tricks were trashed with OS level stack protection and later OS design that randomised stack addresses. Aside from obscure stealth techniques their architecture was trash and the code performance was really poor. The majority of this crap shifted to trojans written in high level languages like C++ where weaknesses in the registry design were exploited instead.

100% agree with you on the trojans/malware crap. =) I think that a lot of the good ones exposed lots of cool bugs in Windows, though I don't agree with the destructive side of the art. Programming is what you make of it; I still find it a bit funny when I think of the beginnings of batch "viruses" and other scripting things.