Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Problem with

Started by absolutzero, September 02, 2021, 12:41:06 AM

Previous topic - Next topic


I d like to thank for masm32 project, especially for unicode support. But I found problems with, which causes errors in assembling.

First problem is in DRAWTEXTPARAMS STRUCT. There is item iTabiLength, but Microsoft defines it iTabLength.

Also I have problem with lfFaceName WORD LF_FACESIZE dup (?) item in LOGFONTW structure in unicode project. I changed it to: lfFaceName BYTE LF_FULLFACESIZE. I dont know, if it is syntactically right, but it works.


Its likely to be a typo from long ago and changing it is the right response.The file was produced back when the reference material was very hard to find and while most of the errors were fixed long ago, you still get the odd quirk that has been missed.



For the UNICODE version (LOGFONTW), the lfFaceName member must be "lfFaceName WORD LF_FULLFACESIZE dup (?)". "lfFaceName BYTE LF_FULLFACESIZE" is for the ANSI version (LOGFONTA).
EC coder


Thanks for replies. I played with LOGFONTW again and it seems, that its declaration in is ok. Problem is rather in its initialisation:

logfnt          LOGFONT <-13,0,0,0,FW_NORMAL,0,0,0,DEFAULT_CHARSET,3,2,1,49,"Lucida Console">

My fix lfFaceName BYTE LF_FULLFACESIZE is assembled without errors, but font name is compiled as ANSI, not UNICODE string. I dont know, how to initialise this structure. I think the best solution of this is move structure to unitialised data section and initialise it at runtime:

logfnt          LOGFONT <>


Try this

logfnt          LOGFONT <-13,0,0,0,FW_NORMAL,0,0,0,DEFAULT_CHARSET,3,2,1,49,{"L","u","c","i","d","a"," ","C","o","n","s","o","l","e",0}>



Fa is a musical note to play with CL



There is another little glitch in, see

Strangely enough, ML.exe, UAsm and earlier AsmC versions never complained about it.


As you may appreciate, producing include file for 32 bit MASM is something like picking fly sh*t out of pepper with a blindfold on and using a blunt pair of pliers to do it. 32 bit MASM is reasonaly picky about what it will accept and 64 bit MASM is a genuine pig to create working include files for.

The testimony to the joys of making include files for MASM is the number of people who have copied them for other assemblers.  :badgrin:


Another testimony to the joys of making include files for MASM is the number of people who have tried (more or less successfully) to produce their own set of includes from various C compilers' header files. You did a pretty good job, Hutch, the glitch I reported is the first in a number of years :thumbsup: