casemap

[JK]

Going through 32 and 64 bit example code i see "option casemap:none", which makes the code case sensitive. But i also often see code without "option casemap ...".

What about "option casemap:all", which makes all code case in-sensitive ? Running a few tests, it seems to work as well. Are there problems with this option (except for case in-sensitivity, which doesn´t allow for multiple definitions for the same name with different capitalisations anymore)?


JK

[jj2007]

With option casemap:none code remains case-insensitive; mov eax == MOV EAX == Mov Eax

We are talking variable names and symbols here, and I would strongly advise against case-insensitive symbols. Especially in longer sources, searching becomes more difficult, and you risk name conflicts e.g. when there are two different macros named Alloc and alloc, from two different libraries. Or think of an exit macro combined with an EXIT: label

I just made a little test with a 64 lines source I am currently working on: POLINK: fatal error: 60 unresolved external(s). for casemap:all

[daydreamer]

take a look at windows code,wndproc uses lots of uppercase constants in switch/case:WM_COMMAND,WM_PAINT...,all VK_CODES
and there are alot more of uppercase constants in windows
so theres a chance you create variables with same names in lowercase and that can cause trouble if you dont have case sensitivity
code I seen also has codestyle when use windows types
RECT rect
HBITMAP hbitmap
POINT point

[hutch--]

You are stuck with writing case sensitive code in Windows among other things due to the format of all of the Windows API functions as well as the messaging unless you want to set up all of the equates used in Windows as well. In the long haul it gives you far more options in naming your own functions and data items when you can write "name Name NAME ThisName ThatName etc ....". One of the few things that drives me nuts with PB is naming conflicts due to the the case insensitivity of the language.

[JK]

One of the few things that drives me nuts with PB is naming conflicts due to the the case insensitivity of the language.

For me it´s just the opposite. I found it always confusing, that "n" and "N" are different variables, which can coexist side by side. Much room for hard to find errors due to wrong capitalisation.

So the conclusion is: having it case in-sensitive (due to casemap:all) is basically possible, but i will have to deal with possible naming conflicts in the includes - right ?


JK

[hutch--]

Its worst than that, Windows programming and the API in particular are C format case sensitive and to go against it means you will have to fully rewrite all of the constants yet not have a method of dealing with case sensitive API functions that are set in their respective DLLs. I have done both in my time but I type everything case sensitive so I don't develop bad habits.

Just as an example, the API SendMessageA/W occurs in that form in the DLL exports and to do otherwise means you will have to create an interpretive layer to use sendmessage or other variants of the original.

You could do it with MASM macros.

sendmessage MACRO arg1,arg2,arg3,arg4
  invoke SendMessageA,arg1,arg2,arg3,arg4
ENDM

Even simpler.

sendmessage equ <SendMessageA>

[JK]

Please note, i don´t want to start a fundamental discussion here. It´s about learning and teaching myself the options i have - all the possibilities and the limitations. What happens, if/when ..., this is a good idea, this is not so good, because of ...

Playing with the following (UASM) code:

Code Select Expand


;*************************************************************************************
;assemble 32
;assemble 64
;*************************************************************************************


ifdef _WIN64
  option win64:15
  OPTION STACKBASE : RBP 

else
  .386
  .model flat, stdcall
  OPTION STACKBASE : EBP 
endif


;option casemap:all                                    ;this makes trouble


include <windows.inc>

includelib kernel32.lib
includelib user32.lib


option casemap:all                                    ;this works


ttt STRUCT
  asdf1  dword ?
  asdf2  dword ?
Ttt ends


.code


start proc
;*************************************************************************************
;
;*************************************************************************************
local n:TTT


  mov N.ASDF1, eax

  invoke messageboxa, 0, CSTR("works"), CSTR("test"), 0
  invoke exitprocess, 0
  ret

   
start endp


end start


;*************************************************************************************
;*************************************************************************************


i see, that the position of "option casemap:all" makes a big difference. Placing it before "include ..." gets me into all kinds of trouble (which is expected). But placing it afterwards, before my own code seems to work like a charm. I don´t have to add/change anything, case doesn´t matter anymore neither for my own defintions nor for the Windows API.

Are there still problems i don´t see (my example is too simple), or is it just like that?


JK

[jj2007]

Try a real life example - 10 errors in 100 lines, pure Masm32, no MasmBasic involved

[hutch--]

All we are trying to do is save you the misery of endless errors and a massive amount of work to adapt around it. No-one would try and stop you from being creative or producing new ideas.

[JK]

Thanks for your input! As mentioned above, i´m playing around to get to know the possibilies and limitations.

@jj2007

Indeed it throws a lot of errors. But changing a few things like "wParam:WPARAM" (which obviously cannot work with casemap:all) makes it run again, i can even make it all lowercase (see attachment).