General 32-bit, 64-bit, ANSI and Unicode questions.

[Relvinian]

Hey All,

First of all, let me apologize if this topic is in the wrong forum.  ;)

It has been a long time since I have been active in the community (10+ years ago).  Since then, a lot has changed in the way of ASM programming for Windows.  ::)  Because of the time length since I have worked with assembly code (mainly MASM), my libraries that I wrote (well over 500+ functions), are in major need of updating to 64-bit.  The libraries I wrote are only 32-bit, but support both ANSI and UNICODE. 

I am also a C / C++ professional developer so I mainly write in that language and also mainly in Unicode. So, here are my questions:

1) With the new OSes and Microsoft dropping support for XP, Vista, etc, are ANSI routines generally not used anymore and everything now basically Unicode?
2) Is 32-bit still primarily used or everything now 64-bit?
3) Should I keep my old versions of ANSI, Unicode, and 32-bit as legacy and concentrate only on Unicode and 64-bit for updating my ASM library?
4) Any good ASM IDEs that support syntax highlighting for the new 64-bit mnemonics?  ie:  rax, rcx, rdx, r8 - r15, etc?  Should I just stick with Notepad++ and/or Visual Studio?

I guess that is all I can think of for now.  Thanks.

Relvinian

[jj2007]

Hi Relvinian,

Welcome back :icon14:

You have many questions and might wish to search the forum. I'll try to answer some of your questions below.

> 1) With the new OSes and Microsoft dropping support for XP, Vista, etc, are ANSI routines generally not used anymore and everything now basically Unicode?

No. Some are using Unicode, but for most purposes Ansi is fine, and Utf8 is another option. My guess would be Ansi 90:10 Unicode. Not all IDE's are good at using it. Here is an example of what is possible with "true" Unicode.

> 2) Is 32-bit still primarily used or everything now 64-bit?

Again, roughly 90:10. While the step from 16 to 32-bit was a huge improvement, 64-bit code is rarely faster (and often slower); one reason being that speed gains from using SIMD have already been realised in 32-bit land. Plus, most people (with the exception of Hutch) never need allocations in the gigabyte range. There is a heated debate here which assembler to use for 64-bit coding - see e.g. the crippleware news thread.

3) Should I keep my old versions of ANSI, Unicode, and 32-bit as legacy and concentrate only on Unicode and 64-bit for updating my ASM library?

Before deciding on anything, study what Hutch has in the pipeline. He is busy working on the 64-bit equivalent to Masm32, and quite advanced. Unfortunately, his library is Microsoft ML64 only, and will not work with the HJWasm and AsmC assemblers. Microsoft dropped HLL support in ML64, i.e. no invoke, no .if ... .else ... .endif etc; workarounds exist, but they are not everybody's taste.

In contrast, both HJWasm and AsmC are fully compatible to the latest versions of 32-bit versions of Microsoft MASM, i.e. they do have all HLL elements; they also assemble 32- or 64-bit sources with the same executable. Besides, their native invoke does proper parameter checking and counting, in contrast to the invoke macro that was designed as a workaround for ML64.

[hutch--]

Relvinian,

That is a name I have not heard for a long time, good to hear from you. Now the IDE question is the simplest one, whatever you like writing code in will do the job as MASM in the Microsoft 64 bit tool set only uses an ANSI character set. There are a couple of tricks to store unicode data, the RC script has long supported unicode data and I have long had a number of tools that will convert unicode text data to DW sized entries in the .DATA section.

UNICODE is straight forward enough as the 64 bit API has extensive support and for a library that you write yourself, you work in WORD sized characters and increment by 2 but if you have already done this in 32 bit, this is simple enough. The base infrastructure is where the difference is and here is where you have to make your choices, you can choose to write 32 bit style code in 64 bit and suffer the same limitations as 32 bit in terms of memory OR you can write code to run in 64 bit mode where you link with the /LARGEADDRESSAWARE option and have access to massive amounts of memory. Its a choice between trying to remain compatible with the past at the cost of poor performance OR designing for the future where 64 bit will dominate.

My own approach was to start from scratch with the 64 bit version of MASM, produce a stackframe that is directly compatible with 64 bit Windows specifications, perform call automation with a MACRO that is working well and write a new library that is fully /LARGEADDRESSAWARE compatible. A near exhaustive set of include files and libraries for Window API functions is up and going and the include files already support an equate that specifies UNICODE API versions instead of the default ANSI versions.

I have recently produced a CHM help file that contains the important technical data on the 64 bit stack format and it documents the library and macros I have done to date. The system is already production quality capable with both EXE and DLL files in modern /LARGEADDRESSAWARE format and can handle very large memory allocations. I have not written any library procedures in UNICODE as yet as I have a lot of other stuff to write.

RE: The choice of assembler you use, I have chosen 64 bit MASM because it is a finished tool that is part of the VC/VS tool set but it is a different tool to the older 16/32 bit version of MASM. For experienced assembler programmers it is a lower level tool that is missing some of the hand holding that the 16/32 bit versions provided but it is simpler and faster to use and with practice you get more code written faster than with the older 32 bit version. The 64 bit pre-processor is just about identical to the older version so macros work much the same way and with the complexity of the Win64 calling convention and stack alignment requirements, the days of simple PUSH/CALL notation is over.

RE: The Watcom clones, I gave up on supporting JWASM because of the author who later abandoned the project. There are two forks supported in this forum which you can check out, both have their own philosophy as to code design and both are under development. I personally got tired of waiting for a finished system as Win64 has been around since about 2004 so I went in the direction of 64 bit MASM as I wanted the capacity in my own lifetime.

Have a look at the stuff I have done so far in the ML64 Development Code subforum. I am in no hurry as I have to write it all myself but its up, running and working correctly.

[jj2007]

whatever you like writing code in will do the job as MASM in the Microsoft 64 bit tool set only uses an ANSI character set.

The main trick is to use UTF-8 as shown here. Even ML64 can assemble that Unicode source.

[ragdog]

Hi

Any good ASM IDEs that support syntax highlighting for the new 64-bit mnemonics?

I use Radasm v3 modded version

Qword´s mod it works for Masm and Jwasm
http://masm32.com/board/index.php?topic=994.0 --

For syntax highlight change the keywords (;Registers) in option code editor.



But i think Visual studio works too.

[Relvinian]

Thank you all for reply and giving me various new options to explore and try to catch up to coding in the various formats.

Right now, I am going back through and fixing any assembling errors of my massive library that does not like to be assembled with ML that comes with VS 2015. 

The first change I noticed have to deal with is definitions.  I guess I used a short hack of VS 6.0 ML.exe when defining variables and checking to see if they were defined.  For example:

Code Select Expand


; VS 6.0 ML.EXE acceptable form
;------------------------------------
#ifdef(_UNICODE)  // MFC unicode defined
STRING_KERNEL32 DW L'kernel32.dll', 0
#elif(UNICODE) // Windows unicode defined
STRING_KERNEL32 DW L'kernel32.dll', 0
#else // ANSI
STRING_KERNEL32 DB A'kernel32.dll', 0
#endif


The above code will not assemble in VS 2015 ML.EXE so this has been my first task. 

Anyway, thanks for all the responses and glad to be in the company of, those who call themselves,  ASM coders, developers, and artists.

Relvinian