As 64-bit CPU is going more popular, 64-bit programing will be a trend sooner or later. So when will we hear the good news that OBJASM64 is released?
Posted on 2007-07-03 22:46:50 by guidry
Hi guidry

I started the OA64 project a few months ago using MASM 8.0 but I reached a point where the bugs were so overwhelming that I decided to stop there and started to consider another compiler like FASM for the 64 bit stuff.
A few minor problems like family attention, work load and a fatal HDD failure had delayed this work and the release of OA32 1.4a, but I?m confident that at least for the last one I?ll release an update soon.

Regards,

Biterider
Posted on 2007-07-04 09:19:16 by Biterider
Hi, there:
      I think not to use Microsoft's assembler is a good choice. Because there is some limitation of the license and I even suspect that Microsoft intends to limit Assembly language. In their .Net framework a new term Assembly is used to mean something that is nothing to do with Assembly language. Because of the copyright, Hutch is not dare to release his MASM64 which makes the evolvment of OBJASM to 64 bits very difficult. So far as I know, OBJASM is built upon many macros, and no other assemblers have more capability than MASM32. In MASM8, the marco functions has been deprecated. I think Microsoft did this on purpose. They want all developers use Visual Studio stuff, I guess. Though FASM isn't  as powerful as MASM32 in regard to macro functions, it's free and open source. Beacuse you as well as many other members, are experts, you will find a way to make OOP in 64-bit Assembly programing possible sooner or later. May God bless you and OOP Assembly!

Sincerely yours,
Guidry
Posted on 2007-07-04 22:17:16 by guidry

In MASM8, the marco functions has been deprecated.

Hi Guidry, can you be more specific on what "macro functions" has been deprecated?
Posted on 2007-08-07 06:40:15 by MazeGen
in masm8 from what I've seen, the macros are extremely buggy. Microsoft got them so messed up, that they can't fix them - thus they flagged macros as deprecated.

The "symptoms" are: crashing ml.exe, locking-up ml.exe, generating wrong opcodes, randomly not-recognizing code, randomly skipping code, randomly adding garbage-bytes in your code,  ...  :shock: . In other words: never use it for your asm projects.
masm8 is usable only as the assembler of cl.exe
Posted on 2007-08-07 07:03:10 by Ultrano
Hi Ultrano, do we talk about ml64.exe version 8.00.50727.42?

I did some successful macro stuff year ago (64-bit fastcall convention macros to replace PROC and INVOKE) and never faced such problems.
Posted on 2007-08-07 07:14:14 by MazeGen
I was using the 32-bit, but I really doubt there's a difference in the macro problems. Because Biterider said "I reached to a point where the bugs were overwhelming". This is exactly the way I found those problems - I was making/improving my ATC (the other OOP package) - and the more complex/large the project became, the more often the "randomly not-recognizing code" happened. I remember myself just putting empty lines to avoid this lol. A bit later I discovered how horrible the binary output is (the "generating wrong opcodes, randomly skipping code, randomly adding garbage-bytes in your code" part). What else would be so overwhelming? Thus, I am sure the same bugs are present in ml64.
Posted on 2007-08-07 07:37:31 by Ultrano
I remember that those old versions (8.00.40310.39, 8.00.40607.16, 8.00.50215.44) were next to useless, but 8.00.50727.42 worked fine for me.

I'm attaching mentioned macros. The project is 80% done, I already did first successful tests. You can see that these macros are not the simplest ones.
Attachments:
Posted on 2007-08-07 07:51:33 by MazeGen
Thanks for your explanation. I wish you could work with Biterider to build OBJASM64.
However, the license is another problem. Isn't MASM8 for noncommercial purpose only ? Can I sell something I write and compile in MASM8 freely? That's why I think open source solution (for example, FASM) may be better.
Posted on 2007-08-08 21:46:58 by guidry
If we speak about OBJASM64, we must take ML64.EXE into consideration. ML64.EXE is part of WinDDK, which is for free and IIRC it comes with very liberal license (actually never read it, but f0dder was speaking about it at this board). The only problem is that last time I downloaded WinDDK (1 year ago?), ML64.EXE was 8.00.40310.39, which is useless. You can try to check WinDDK now if this changed.
My ML64.EXE comes from VS2005, which is not for free.
Posted on 2007-08-09 01:01:35 by MazeGen
Sorry to start up a quiet thread again, but I have recently tried MASM 8 and I must agree that the changes they made are terrible, since they could've adjusted the macros for the new calling convention, etc.  However, I can partly see why they didn't (parameter names needing to be made synonymous with register names could need a lot of change).

Before version 1.0 of PwnIDE (a long way off, but still...) I'm hoping to have built-in assembling, including customization of calling conventions, so that 32-bit and 64-bit code can be interchanged without any changes to the code (other than making sure to check sizes of things and removed instructions).  I was wondering if anyone has already made macros for customizing calling conventions (i.e. replacing invoke, the prologue, the epilogue, and defining the parameter names), since this would let me put off this rather difficult feature until later, when I do built-in compiling for other languages.

Edit: I forgot to mention replacement of the PROC directive too, since that's also busted in MASM 8.
Posted on 2007-08-18 14:47:58 by hackulous
I was wondering if anyone has already made macros for customizing calling conventions (i.e. replacing invoke, the prologue, the epilogue, and defining the parameter names), since this would let me put off this rather difficult feature until later, when I do built-in compiling for other languages.

Edit: I forgot to mention replacement of the PROC directive too, since that's also busted in MASM 8.


See my earlier post for attachment. I have already done something one year ago, but there was no progress since then (didn't do any 64bit coding last year). I hope I can revert to this project and release it until the end of this year.

If you are in a hurry, I can release the project in this stage with some examples and documentation. It works, but it uses GoAsm-like way to handle 64-bit stack alignment so it produces a lot of additional instructions. I will add a possibility to get rid of them.
Posted on 2007-08-20 04:08:12 by MazeGen

If you are in a hurry,

Cool.  I'm not really in a hurry, since version 1.0 is a long way off.  I'm at version 0.1.7 right now, which is a pre-alpha version, and I'm hoping to get to 0.2 (alpha) by the end of September, though I may not get everything together by then.  (In case you've tried it and are baffled on how to use it, it's probably due to the lack of certain features, and I'll put out a video tutorial after the alpha release.)

For the next while it'll just be supporting 32-bit assembly, but I'm hoping to support 64-bit without having to change a lot, hopefully by the beta version.  One of the objectives for version 1.0 is having the ability to mix other languages as well.  Doing both of those would mean either having some sort of macros to handle calling conventions in 64-bit assembly, or writing my own preprocessor/assembler, since I've been working under the assumption that any languages would have some sort of construct like a function with parameters.  (Writing a preprocessor would basically be the same as writing macros for it anyway.)

I would like to eventually get around to writing my own assembler anyway, since built-in assembling and debugging would be quite useful, but that could take quite a long while (if only for the high-level assembly macros, since I've already got encoding data for the rest).  As such, it'd just be easier to use macros until I get to that point.

For the moment, I just can't wait until I get the alpha ready, so anything else is icing on the cake.  :)

Edit: As a frame of reference, I'm hoping to get to version 1.0 sometime in summer 2009, since I may want to make a company of it once I graduate.  I'll probably keep the assembly language portion free and open source, since companies would mostly be interested in C/C++/C#/Java etc.
Posted on 2007-08-20 14:29:56 by hackulous