Recent Posts

Pages: [1] 2 3 ... 10
1
The Workshop / Re: Microsoft MASM bug
« Last post by hutch-- on Today at 01:08:35 PM »
> No. That's why I proposed the other solution: use UAsm

MASM has been around for over 35 years, should we hold our breath waiting for the alternatives ?  :P

Watcom died in the arse, JWASM barely made 5 years and MASM is still going strong, should we be worried ?  :lol:
2
Romper Room / Re: This is a test
« Last post by mineiro on Today at 12:47:01 PM »
Testing snapshot of Mozilla Firefox, expires in 14 days

https://screenshots.firefox.com/o2ZTuWEOEjVwtc7r/www.google.com

3
The Campus / Re: Tool buttons with icons?
« Last post by 2B||!2B on Today at 12:41:48 PM »
Yes needs those those dlls if your using those RadASM special controls.
Yes, I agree, a static library option would have been handy. Although it is possible to modify then to be static libraries - but you would have to change a few bits and pieces and manually call the DllInstall function (which can be renamed - so its kind of similar to the ModernUI register functions in that way).

I did do that with the RAHex control - from the original source on sourceforge - to make it a standalone static component. Although it did mean putting together a few support functions to help setup the control beforehand as there is a lot of little bits and pieces it needs - different fonts and other things for it to load and work. I might gather that together and post that up if its useful for someone to have a static hex control - I've only used it as a hex viewer for small amounts of data, not looked at the editing and saving part - all to do with richedit control streams for reading in and writing out.

Perfect man. How long does it take to modify one RadASM control to make it like your MUI examples (that no longer needs the dlls)?

Also, check your PM.
4
MasmBasic & the RichMasm IDE / Len, wLen, uLen
« Last post by jj2007 on Today at 12:17:04 PM »
include \masm32\MasmBasic\MasmBasic.inc         ; download
  Init
  Let esi="Нажмите на эту кнопку"              ; "Click on this button" in Russian
  Print Str$("Len(esi)=\t%i\n", Len(esi))      ; treated as Ansi
  Print Str$("uLen(esi)=\t%i\n", uLen(esi))    ; treated as Utf8
  Print Str$("wLen(esi)=\t%i\n", wLen(wRec$(esi)))     ; treated as Unicode (wRec$: convert Utf8 to wide string)
  Print
  Let esi="在這裡輸入文字"                       ; "Enter text here" in Chinese
  Print Str$("Len(esi)=\t%i\n", Len(esi))      ; treated as Ansi
  Print Str$("uLen(esi)=\t%i\n", uLen(esi))    ; treated as Utf8
  Print Str$("wLen(esi)=\t%i\n", wLen(wRec$(esi)))     ; treated as Unicode
EndOfCode


Code: [Select]
Len(esi)=       39
uLen(esi)=      21
wLen(esi)=      21

Len(esi)=       21
uLen(esi)=      7
wLen(esi)=      7

Note that the uLen macro does not check whether the string is valid Utf8 (credits to PaulSquires). Example:

  Let esi="Click on this button"+Chr$(169)      ; Ansi with one extra character
  .if rv(MultiByteToWideChar, CP_UTF8, MB_ERR_INVALID_CHARS, esi, Len(esi), NULL, 0) == 0
        PrintLine "[", esi, "] is not a valid Utf8 string"
  .else
        Print "[", esi, "]", Str$("has %i bytes and is a valid Utf8 string\n", eax)
  .endif


Code: [Select]
[Click on this button©] is not a valid Utf8 string
Len(esi)=       21
uLen(esi)=      21
wLen(esi)=      21

Full project attached.
5
The Workshop / Re: Microsoft MASM bug
« Last post by jj2007 on Today at 11:59:00 AM »
No. That's why I proposed the other solution: use UAsm :P
6
The Campus / Re: BITMAP STRUCT in win64.inc
« Last post by zedd151 on Today at 07:18:16 AM »
But if you use the wrong name, ml throws an error. Thats when I first encountered it. I had not known at the time that the names were specified differently in win64.inc and windows.inc.
7
The Campus / Re: BITMAP STRUCT in win64.inc
« Last post by Vortex on Today at 07:15:09 AM »
Hi zedd,

The member names of the structures are not important for the assemblers\compilers. They are necessary for us to read and distinguish them.
8
The Campus / Re: BITMAP STRUCT in win64.inc
« Last post by zedd151 on Today at 06:51:28 AM »
Hi zedd,

Thinking now about the structure :


The last DWORD entry is for the alignment.


Okay, I'll buy that.



Quote
The small name differences like mPlanes vs bmPlanes should not be a problem.


But for a conversion to 32 bits, the names would have to be changed then, as I have done to reflect the names in windows.inc. (32 bit)


Reference:


gdi BITMAP STRUCT
9
The Campus / Re: BITMAP STRUCT in win64.inc
« Last post by Vortex on Today at 06:45:20 AM »
Hi zedd,

Thinking now about the structure :

Code: [Select]
  BITMAP STRUCT
    bmType   LONG ?
    bmWidth   LONG ?
    bmHeight  LONG ?
    bmWidthBytes LONG ?
    mPlanes   WORD ?
    mBitsPixel  WORD ?
    DWORD ?
    mBits   LPVOID ?
  BITMAP ENDS

The last DWORD entry is for the alignment. The small name differences like mPlanes vs bmPlanes should not be a problem.
10
The Campus / BITMAP STRUCT in win64.inc
« Last post by zedd151 on Today at 06:38:39 AM »
While converting a program down to 32 bits, I noticed a potential flaw in win64.inc (as pointed out by Vortex)


The BITMAP structure in Windows.inc (32 bit) is defined as


Code: [Select]



BITMAP STRUCT
  bmType        DWORD       ?
  bmWidth       DWORD       ?
  bmHeight      DWORD       ?
  bmWidthBytes  DWORD       ?
  bmPlanes      WORD        ?
  bmBitsPixel   WORD        ?
  bmBits        DWORD       ?
BITMAP ENDS

in win64.inc:

Code: [Select]
  BITMAP STRUCT
    bmType   LONG ?
    bmWidth   LONG ?
    bmHeight  LONG ?
    bmWidthBytes LONG ?
    mPlanes   WORD ?   ;<-- error?
    mBitsPixel  WORD ? ;<-- error?
    DWORD ?                ;junction?
    mBits   LPVOID ?      ;<--error?
  BITMAP ENDS






Pages: [1] 2 3 ... 10