Error: line too long while using backslash

[zedd151]

ml64.exe handle only ASCII and UTF-8 without signature source files.

I figured only ascii after I tested my "odd" notion that I had this morning while pondering the original problem.
Good to know for future reference.

[hutch--]

ML64 does not support UNICODE text but there are a couple of method to include UNICODE text, in a resource file OR as DB data. The ANSI to UNICODE conversion will only do the first 256 characters but if you have genuine UNICODE from arabic or oriental sources, you need a method of storing it. A resource file works but its a bit clunky to use and DB format UNICODE is bulky and not editable.

[jj2007]

Okay, my theory didn't quite work at all. Saved the file as uncode this is the response:

Strangely enough, when I open your Unicode source in RichMasm and hit F6, it assembles & runs just fine... but when I use the makeit.bat, I see lots of error messages

The reason is that RichMasm doesn't care whether it opens an Ascii or UTF-16 file, but for building the source it always exports Ascii or Utf-8

I figured only ascii

The Assembler has no idea what Utf-8 looks like; so it assumes "Ascii".

[zedd151]

Strangely enough, when I open your Unicode source in RichMasm...

When I posted the 'saved as unicode' version, it was just an experiment on my part. Not suggesting anyone else should use that (saving as unicode).

[TimoVJL]

The Assembler has no idea what Utf-8 looks like; so it assumes "Ascii".

Good point is, that it don't mess with ANSI codebases, but i haven't tested it enough.

[jj2007]

When I posted the 'saved as unicode' version, it was just an experiment on my part. Not suggesting anyone else should use that (saving as unicode).

It was worth a test. I just checked with UAsm and AsmC, same as ML64: no luck with a Utf-16 source.

The Assembler has no idea what Utf-8 looks like; so it assumes "Ascii".

Good point is, that it don't mess with ANSI codebases, but i haven't tested it enough.

Save & build everything as Utf-8; then, if Windows asks for it, convert Utf-8 to Utf-16. It works.

[TimoVJL]

Windows NT have been internally UNICODE since born, why ml/ml64 don't still accept that ?

[hutch--]

I think its a case of what assemblers have generally been used for over a long period. The memory demand being just one of them. If you need to deal with text in a non european character set, UNICODE is very useful but if you are doing anything else, the 256 character set is half the size and a more efficient use of memory.

[daydreamer]

I think its a case of what assemblers have generally been used for over a long period. The memory demand being just one of them. If you need to deal with text in a non european character set, UNICODE is very useful but if you are doing anything else, the 256 character set is half the size and a more efficient use of memory.

when I worked with 06xx arabic and hiragana and katakana I tested do storage of only the lower byte and add 0600 or where hiragana or katakana start
isnt that something similar to utf8 works?
probably invain when posting .zip in forum,it probably compress lots of 06 bytes

[bluedevil]

@jj
How are you doing this? Code on your zip file also compiles on my machine right now!!!

Zip your non-assembling source and post it here. I am curious, too.

OK I've solved your magic @jj. :D

You had shared this code:

Code Select Expand


    invoke  CreateWindowEx, \
                WS_EX_CLIENTEDGE, \
                addr ClassName, \
                addr AppName, \
                WS_OVERLAPPED or WS_CAPTION or WS_SYSMENU or WS_MINIMIZEBOX or WS_MAXIMIZEBOX or WS_VISIBLE, \
                CW_USEDEFAULT, \
                CW_USEDEFAULT, \
                CW_USEDEFAULT, \
                CW_USEDEFAULT, \
                NULL, \
                NULL, \
                hInst, \
                NULL


And this is my non-compiling code:

Code Select Expand


    invoke  CreateWindowEx,
                    WS_EX_CLIENTEDGE, \
                    addr ClassName, \
                    addr AppName, \
                    WS_OVERLAPPED or WS_CAPTION or WS_SYSMENU or WS_MINIMIZEBOX or WS_MAXIMIZEBOX or WS_VISIBLE, \
                    CW_USEDEFAULT, \
                    CW_USEDEFAULT, \
                    CW_USEDEFAULT, \
                    CW_USEDEFAULT, \
                    NULL, \
                    NULL, \
                    hInst, \
                    NULL


At first they seem equal but, i have added one more tab to each line. So this makes more than 512 chars. Remember what M$ Docs said:

line too long

A source-file line exceeded the limit of 512 characters.

If multiple physical lines are concatenated with the line-continuation character ( \ ), then the resulting logical line is still limited to 512 characters.

Anyway, I got the situation. I will be more careful while coding and try not to exceed 512 chars.

Thanks everyone for your valuable comments.

[jj2007]

Anyway, I got the situation. I will be more careful while coding and try not to exceed 512 chars.

Try UAsm64, its limit is 1004 chars ;-)

[bluedevil]

Anyway, I got the situation. I will be more careful while coding and try not to exceed 512 chars.

Try UAsm64, its limit is 1004 chars ;-)

I am taking this as a note :D

BTW is it 1004 or 1024?

[jj2007]

BTW is it 1004 or 1024?

Strangely enough, it's 1004

[hutch--]

Funny enough, I have never found line length to be a problem that cannot easily be overcome. For Windows styles, OR them all to either a variable or register, instead of "ADDR whatever", use a pointer instead "pText". With quoted text, multiline layouts with a separate DB for each line allows very large text to be embedded in an exe file.

[HSE]

Strangely enough, it's 1004

You can rebuild UASM with longer lines, no restriction. Usually I set maximum line size to 2048 bytes, but my longer mesured line only was 1680 bytes.