Ok, I'm starting to get very annoyed by the "line too long" error in the MASM compiler by now. :mad:
It keeps popping up all the time, forcing me to make my code much more ugly and complex than necessary. :(

Is there any way to increase this limit of how long lines can be? Please, please, I beg you, someone? :)

I have quite many macros in the code I'm working with right now, and to some of them I pass multiple strings as parameters in their calls, e.g. like this:



STRING_PROCESSING_MACRO "This is a parameter string", \
"This is also a parameter string", \
"Soon there can't be any more parameter strings", \
"The stupid error will probably pop up somewhere around here"

And when I try to compile it, I get the following error from the compiler:

"error A2039: line too long"


I solve this by putting each of the strings in temporary text macro objects, like this:




P1 textequ <"This is a parameter string">
P2 textequ <"This is also a parameter string">
P3 textequ <"Soon there can't be any more parameter strings">
P4 textequ <"The stupid error will probably pop up somewhere around here">
STRING_PROCESSING_MACRO P1, P2, P3, P4

But this is not good at all, and very ugly. :(


So, is there any way to increase this line length limit in MASM? I'll even patch ml.exe if I have to, just please help me! :)

If the answer to that question is "no", is there at least a nicer way to accomplish the macro call in the example above than my ugly solution?


Any and all suggestions would be greatly appreciated.

Thanks!
Posted on 2002-12-23 19:34:26 by dELTA

... So, is there any way to increase this line length limit in MASM? I'll even patch ml.exe if I have to, just please help me! :)


You will quickly receive little to no help around here if you ask us to help patch anything. Careful for what you write.

No, there is not *legal* means to make a string longer than 512 characters.
If you want more, i sugest C++ or simular HLL compilers.

:NaN:
Posted on 2002-12-23 22:39:05 by NaN
Ok, sorry about that, I really didn't mean it like a crack or anything, just like a functionality improvement for personal usage, and it was only a last way out, and mostly a way to express how eager I was to get past this problem. :(

Anyway, is there any "common way" to get past this problem with calling macros with too long parameters? There must be quite a few people having the same problem every now and then, right? I would really guess that some of them have come up with a better solution than the one I'm using? :)

Thanks!
Posted on 2002-12-24 05:34:17 by dELTA
STRING_PROCESSING_MACRO db "This is a parameter string",
db "This is also a parameter string",
db "Soon there can't be any more parameter strings"
db "The stupid error will probably pop up somewhere around here"

like this.
Posted on 2002-12-24 05:51:50 by Hiroshimator
Hmm, could you please explain that a bit further?

I just tried it, and it gave a lot of errors ("missing parameter" error for the macro for example). It also seems strange just intuitively to call a macro by placing a bunch of "db <string>" items after it? How would the macro know that those strings belong to it (especially when using vararg parameters)? Won't those strings just be placed directly in the code segment when doing like that?

Thanks a lot anyway, I hope you can clearify this further, so that I can understand, and get around this problem.
Posted on 2002-12-24 06:38:42 by dELTA
What Hiro is refering to is NOT placing the null after the first line, when you declair a string in the .data segment:

.data


szText db "String of text",0

For multiple lines, drop the null, and contrinue:

szText2 db "Sting of text on the first line "
db "That will automatically be concatenated to the one "
db "before, because in memory this is just one LONG array of "
db "bytes as declaired by the db at the begining of each line. "
db "All these bytes are addressed initially by szText2 and since "
db "there is no NULL, string routines will keep parsing memory until "
db "it findes this null", [b]0[/b]
Posted on 2002-12-24 08:13:20 by NaN
Yup... i think Hiro had an extra comma at the end of the first two lines which are causing you the grievances!

STRING_PROCESSING_MACRO db "This is a parameter string",
db "This is also a parameter string",
db "Soon there can't be any more parameter strings"
db "The stupid error will probably pop up somewhere around here"

like this.
Posted on 2002-12-24 09:26:46 by jademtech
And no NULL... so if used, it wouldnt stop when the string ended.

:alright:
NaN
Posted on 2002-12-24 09:33:38 by NaN
This works because the thing before the first db acts as a label and all the subsequent lines just define data. That was a bit unclear, so i'll try to elucidate further :grin:



szHW db "Hello "
db "world",0

invoke Bleh, addr szHW


A label is created for szHW and bytes are written starting from the label - "Hello world",0. So addr gets the location of the beginning of the string, szHW...

i sometimes use this to lop off some bytes from strings (not sure if this is bad practice or not):



szFileName db "An untitled file"
szLoadedMsg db " is currently loaded.",0


i used something similar to set the window title of a notepad-like program. When no file was loaded, it loaded a string starting at FileName. Otherwise, it loaded the file name from another memory location and appended szLoadedMsg to it.

btw, not exactly sure how splitting up a string like the first example will affect sizeof... not going to look it up or test.
Posted on 2002-12-24 09:36:40 by jademtech

And no NULL... so if used, it wouldnt stop when the string ended.

:alright:
NaN


lol... true dat :grin: it could, however, be passed the string length, like for some old DOS interrupts :rolleyes:
Posted on 2002-12-24 09:37:18 by jademtech
Thanks for all the input guys, but sadly I don't think that this really adresses my real problem. :(

I want to pass the strings as text macro strings (i.e. they should not be put in the actual exe-file first, and then referenced). For example, I might want to encrypt them directly in the exe-file with a macro, and then decrypt them during runtime. Then they need to be passed as pure text macro strings (enclosed in <>) and not like that. :(

But I guess I'll just have to give up and resort to my original solution then. I just don't understand how they could implement such a crappy limitation in the MASM compiler, which is otherwise so powerful. :(

Thanks anyway everyone!
Posted on 2002-12-24 10:58:11 by dELTA
I don't really see the problem, it just depends on what you want to do. The standard format,

name db "text"
db "more text"
db "even more text again",0

works fine.

If you want to put it in a macro,

MyText MACRO
name db "text"
db "more text"
db "even more text again",0
ENDM

In initialised .DATA

.DATA
MyText

Regards,

hutch@movsd.com
Posted on 2002-12-24 20:29:04 by hutch--
I usually write as this to make it clear:
VersionInfo Label Byte
db "Small Utility for File Search", 0AH,0DH
db 0DH, 0AH
db "Author: Smallwaves.",0DH,0AH
db " Other Info", 0DH,0AH
db 0;end flag.
or if it's a array of structure, just like this:
NodesArrary Label Node
Node <,,>
Node <,,>

:rolleyes:
Posted on 2002-12-25 03:12:56 by smallwaves
Ok, either I'm very stupid, or there's a lot of misunderstanding of my question going on here. :)

Once again:

What I want to do:

* Call a macro with several text macro type string parameters (i.e. the type of strings that are inside <> delimiters, meta-data) without having to limit these parameters to short strings due to the line-length limitation problem in MASM.


What I do not want to do:

* Use (references to) strings that are located in the actual exe-image of the program (the macro might for example encrypt the strings before storing them in the actual program data).

* Define a macro, I know how to do that. :)


Please read my original post in this thread for more info. :tongue:


Thanks everyone. :alright:
Posted on 2002-12-25 06:34:18 by dELTA
dELTA,
Obviously the line buffer in MASM is a generous finite length. If it were a ridiculous 16K, or had a virtual buffer manager, then someone would try to write a book using a macro. Without access to the MASM source, or the ability to evaluate and patch an extremely complex program, there isn't too much anyone can do about it. A line has a predetermined length, and that's it.

The below example below is what I used to initialize a large structure. It is similar to your method. I could not fit all the initialization between the brackets without running out of space. It might be ugly, but at least it's clear. By the way, it appears that mulitple consecutive space characters and comments use up room in the line buffer too. Ratch



S1 TEXTEQU \
<PIXELFORMATDESCRIPTOR,\ ;size of this pixel format descriptor
1,\ ;version number
PFD_DRAW_TO_WINDOW OR \ ;format must support window
PFD_SUPPORT_OPENGL OR \ ;format must support OpenGL
PFD_DOUBLEBUFFER,\ ;must support double buffering
PFD_TYPE_RGBA> ;request an RGBA format
S2 TEXTEQU \
<8,\ ;select our color depth
0,0,0,0,0,0,\ ;color bits ignored
0,\ ;no alpha buffer
0,\ ;shift bit ignored
0> ;no accumulation buffer
S3 TEXTEQU \
<0,0,0,0,\ ;accumulation bits ignored
16,\ ;16Bit Z-buffer (depth buffer)
0,\ ;no stencil buffer
0,\ ;no auxiliary buffer
PFD_MAIN_PLANE,\ ;main drawing layer
0,\ ;reserved
0,0,0> ;layer masks ignored

pfd PIXELFORMATDESCRIPTOR {S1,S2,S3} ;pfd tells windows how we want things to be
Posted on 2002-12-25 09:27:11 by Ratch
I wouldn't really call it "generous" when it doesn't even allow relatively commonly used constructs, and happen to me every now and then, but anyway.

And I can't really see the disadvantage of having a 16k or dynamic size buffer either. So what if someone wrote a book with a macro? They would have ugly code, and the rest of us would never have to be bothered with useless errors in our beautiful code, that's all. ;) It's simply clean and beautiful not to have unfounded static limitations in a product, so Microsoft disappoints me somewhat here. :(

And yes, I noticed too that all whitespaces are included in the count, which makes it even more ugly, and dependant on the current indentation level too. :(

Finally, thanks for your example!
Posted on 2002-12-25 11:46:41 by dELTA
dELTA,

Its always been the case of finding out what a tool will do and working within its capacity, do it the other way around and you will end up with problems of the type you have.

====================================
* Use (references to) strings that are located in the actual exe-image of the program (the macro might for example encrypt the strings before storing them in the actual program data).
====================================

Now some of what you want to do is no big deal to do, what you write in a macro is NOT contained in the exe image until you use the macro.

Make a macro header file with many different macros in it which are sized to give you the granularity you require.

Nest them if you need some of the groupings larger.

Call only the macros you require and you file only contains what you want.

The requirement to encrypt the data before it goes into the .DATA section is something that an assembler cannot do as placing data in the .DATA section (or the code section if you wanted to) occurs BEFORE the file in assembled. To do this you would need some form of preprocessor to do what you are after.

Regards,

hutch@movsd.com
Posted on 2002-12-25 17:08:33 by hutch--
Hutch,

I know very well that things that are written inside macros are not put in the exe-file until the macro is called, but it would be pretty useless to write a new macro for every single text I want to put into the file. The task of dynamic code/data-generation, by use of parameters, is exactly what macro's are mainly for, and hence I find it quite unfortunate that the process of passing parameters to them has functionality-restricting limits on them like this in MASM. That's all.

And no, text-macro type strings (the ones delimited by <>) are not put into the exe-file before it is assembled. And it is indeed possible to encrypt data before it is put into the exe-file by using macros. And "To do this you would need some form of preprocessor"? :confused: If you don't classify macros and conditional assembly operators as a preprocessor activity, I don't know what could be called so?

Here's a simple example for you (please excuse any syntax errors, it's only a conceptual example, written in 30 seconds off the top of my head):



ENCRYPT_STRING MACRO plaintext_string:REQ, \
data_label_name:REQ

encrypted_result TEXTEQU <>
FORC current_plain_char, <plaintext_string>
current_crypted_char TEXTEQU %(current_plain_char XOR 0FFh)
encrypted_result catstr encrypted_result, current_crypted_char
ENDM
.data
data_label_name: db "&encrypted_result", 0
.code
ENDM

This macro would be used like this in the code:


ENCRYPT_STRING <This string will be encrypted in the exe>, crypted_str

and an equivalent decryption operation would have to be used during runtime before using the string in the program.


So, as much as I appreciate your info and advice, I must ask you to please not accuse me of things like not knowing what my tools can do, at least not without having reasonable grounds for it. Believe me, I mostly do (in this case at least, and I do my best to do so in other cases too). Also, it might not be a good idea for you to post here that MASM can't do things that it indeed can do. Being a person of your respect around here and everything, many people might believe you, and then become unnecessarily dishearted.

Thanks!
Posted on 2002-12-25 18:11:41 by dELTA
Unless there is a command line option to increase line length, you're stuck with the line length limit of MASM.

You will need to devise a way to do the equivalent work in incremental macro calls, rather than as a one-step macro.
Posted on 2002-12-25 18:35:52 by tenkey
dELTA,

----------------------
So, as much as I appreciate your info and advice, I must ask you to please not accuse me of things like not knowing what my tools can do, at least not without having reasonable grounds for it. Believe me, I mostly do (in this case at least, and I do my best to do so in other cases too). Also, it might not be a good idea for you to post here that MASM can't do things that it indeed can do. Being a person of your respect around here and everything, many people might believe you, and then become unnecessarily dishearted.
----------------------

Nah, you are barking up the wrong tree here, what I see you doing is leading with what you WANT to do but running into a limit that prevents it.

----------------------
The task of dynamic code/data-generation, by use of parameters, is exactly what macro's are mainly for, and hence I find it quite unfortunate that the process of passing parameters to them has functionality-restricting limits on them like this in MASM.
----------------------

This is where I see your problem, MASM macros are crude at best but can do a reasonable amount of simple preprocessing if you can be bothered with it. What it is doing as a preprocessor is exactly the opposite of what you have described, "code/data-generation". It is STATIC insertion of code into source BEFORE it is assembled. Dynamic code is what you do with instructions AFTER it is up and going as an assembled binary file.

What I did suggest to you is do your own preprocessing BEFORE you pass it to MASM, if you like, PRE-preprocessing of the data you want encrypted and just place it in the data section where you want. This can of cource generate other problems like the encrypted data will not work in the DB format you want to use but you can automatically generate DB data in table form as ascii characters, insert that into either the code or data sections and call it from the start address.

This stuff is technically trivial to do as long as you understand the limits of the assembler you are using.

Regards,

hutch@movsd.com
Posted on 2002-12-26 04:16:53 by hutch--