CHR$()

[Mark Jones]

 Hello, is it okay to use a ' character in CHR$("") text? i.e.,

Code Select Expand


print chr$(" Mark's String ")


I'm getting some unusual compilations and think this may be the culprit.

Thank you. :)

[hutch--]

Mark,

Thi is the macro directly from macros.asm

Code Select Expand


      chr$ MACRO any_text:VARARG
        LOCAL txtname
        .data
          txtname db any_text,0
        .code
        EXITM <OFFSET txtname>
      ENDM

LATER :

These all work OK.

Code Select Expand


    print chr$("left square bracket ",60),13,10
    print chr$("right square bracket ",62),13,10
    print chr$("Exclamation character ",33),13,10
    print chr$("Enclosed quotes ",34,"Quoted Text",34),13,10
    print chr$("Enclosed alternate quotes 'Quoted Text'"),13,10


Effectively anything you use as parameters is written directly to the data section so as long as you are using valid syntax for that purpose, it should work fine. Where you can get into trouble is with rese5rved characters used by MASM so you seperate the character and use its ASCII number instead.

[Jeff]

LATER :

These all work OK.

Code Select Expand


print chr$("left square bracket ",60),13,10
print chr$("right square bracket ",62),13,10
print chr$("Exclamation character ",33),13,10
print chr$("Enclosed quotes ",34,"Quoted Text",34),13,10
print chr$("Enclosed alternate quotes 'Quoted Text'"),13,10


Effectively anything you use as parameters is written directly to the data section so as long as you are using valid syntax for that purpose, it should work fine. Where you can get into trouble is with rese5rved characters used by MASM so you seperate the character and use its ASCII number instead.

for reserved characters, couldnt you also use the exclamation point escape character since chr$ is a macro?

Code Select Expand

    print chr$("left square bracket !<"),13,10
    print chr$("right square bracket !>"),13,10
    print chr$("Exclamation character !!"),13,10
    print chr$("Enclosed quotes ",34,"Quoted Text",34),13,10
    print chr$("Enclosed alternate quotes 'Quoted Text'"),13,10
;also...
    print chr$('Enclosed alternate quotes "Quoted Text"'),13,10

[RuiLoureiro]

Sorry Hutch,
                 Does EXITM return a pointer in EAX ?

Code Select Expand


         chr$ macro ...
         ...
         EXITM <OFFSET txtname>
         ...
 

[hutch--]

Jeff,

That is another method that works fine. I personally never liked escape characters but its a sign of age.  :bg

Rui,

EXITM returns whatever is enclosed in the angle brackets.

[Mark Jones]

Hmm. Here's the lowdown: I was tinkering around with Fraiseur's code and have ran into a reoccuring problem. It seems that, on rare occasion, something in the code causes a compile issue where the EOF of the compiled executable falls short of a 1k boundary. For example, this is a binary dump of the EOF of a recently compiled exe:

Code Select Expand


00000BC0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000BD0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000BE0: 0000 0000 0000 0000 4D53 4945 002E 000D  ........MSIE....
00000BF0: 0A00 0000                                ........


Because the file falls short of BFFh, windows will not run it - "not a valid win32 executable." If I manually fill in bytes up to BFF with nulls, it will execute without error.

MASM32/link produces the malformed .exe without any error whatsoever, which leads me to believe this is either a very obscure bug, or a hardware/OS issue (although that seems unlikely, with no other issues known.)

Patching the missing bytes in the malformed .exe, and comparing that with a "working" compiled exe, yields many differences. So the files are not otherwise identical. Examples are included.

The exact issue causing the malformed executable is proving very hard to pin down. In the attached project, it currently produces a bad executable. To make it produce a working one, comment out the unused and seemingly innocent "somevar" string. OR, comment out the first of the two print commands which have ' in their string - see the comments. The code runs fine when it compiles properly. Other than that, the results are very unstable. Changing the number of strings, length of them, their values, the order of code, or contents sometimes has an effect, but follows no logical pattern. ::) :(

WinXP Pro SP1, NTFS (4k clusters)
ML.EXE v7.00.9210

[attachment deleted by admin]

[pbrennick]

Hi Mark,
I have tried to reproduce your problem using the 6.14.8444 version of ml.exe and I cannot.  Perhaps this is an issue with the 7.0 version of ml.exe?

EDIT:  Actually, I cannot reproduce your problem no matter what version of ml.exe I use.  Maybe you could install SP2?  Actually, I have no clue but I know SP1 had issues.

Paul

[hutch--]

MArk,

Another thing to try is Pelle's linker instead of the standard Microsoft linker as it may give you a different result.

[Mark Jones]

I'm making an update to my makeit.bat project to allow pelle's linker. I reassembled this project using POLINK and it compiles and runs fine. I am very baffled why the MS linker will STILL repeatedly malform this executable. :dazzled:

[pbrennick]

Hi Mark,
Pelle's linker is an excellent product.  You are making a good choice.

Paul