News:

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 windows.inc

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

Previous topic - Next topic

absolutzero

I d like to thank for masm32 project, especially for unicode support. But I found problems with windows.inc, 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.

hutch--

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.

rsala

Hi,

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

absolutzero

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

.data
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:

.data?
logfnt          LOGFONT <>


Biterider

Hi
Try this

.data
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}>


Biterider

TouEnMasm

Fa is a musical note to play with CL

absolutzero


jj2007

There is another little glitch in WinExtra.inc, see http://masm32.com/board/index.php?topic=9890.msg108391#msg108391

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

hutch--

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:

jj2007

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: