There are two things that come to mind that are both easy enough to impliment and useful to assembler language programmers in Windows.
1. Direct UNICODE support for string data.
2. The capacity to directly include a binary file in either the .CODE section or the .DATA section.
The first would be something like a new datatype of WORD size (2 bytes) that will accept string data and read each byte as a unicode character. The API already exists to do this conversion with MultiByteToWideChar() and the suggested notation would be in two forms like normal, WC ond WCHAR. The capacity to embed literal characters may not be politically correct, socially acceptable or "nice" which are all good reason to have it in an assembler.
The second would be a KEYWORD something like INCLUDEBIN or INCLUDEFILE and it would dump the content of the required file directly into the source code in either the .CODE or .DATA section in exactly the same way as a DB sequence that is existing capacity. It would not only be convenient but it would save ML form converting DB sequences to direct binary which would be a lot faster.
Perhaps its time to see the end of 256 character data as well.
Quote
Perhaps its time to see the end of 256 character data as well.
That would be like a dream come true.
Paul
QuoteThe capacity to directly include a binary file in either the .CODE section or the .DATA section.
Nice idea :U Currently, to include a binary file in the data section, we are forced to use a bin2obj converter for Masm.
Quote from: hutch-- on May 14, 2005, 11:43:10 AM
There are two things that come to mind that are both easy enough to impliment and useful to assembler language programmers in Windows.
1. Direct UNICODE support for string data.
2. The capacity to directly include a binary file in either the .CODE section or the .DATA section.
The first would be something like a new datatype of WORD size (2 bytes) that will accept string data and read each byte as a unicode character. The API already exists to do this conversion with MultiByteToWideChar() and the suggested notation would be in two forms like normal, WC ond WCHAR. The capacity to embed literal characters may not be politically correct, socially acceptable or "nice" which are all good reason to have it in an assembler.
Having looked at this problem recently, what's really needed is support for various character formats, including:
1. Old fashioned 16-bit Unicode (which is what Windows supports internally).
2. UTF-16
3. UTF-8
4. UTF-7.5
5. UTF-32
6. ANSI
7. 7-bit ASCII
As all of these character types appear in various applications, it would be nice for an assembler to provide native support for them all. IMO, UTF-8 seems to be the most important one to support (after ASCII, of course; I'm assuming all assemblers already provide support for ASCII/ANSI character sets).
The real issue, however, isn't so much the assembler as it is the editor one uses to create assembly source files and the printer drivers that will print those source files. E.g., most assemblers today will actually handle UTF-8 appearing within quotes in a literal string. But the ability to get those characters between the quotes (and display them properly) is a different issue.
Quote
The second would be a KEYWORD something like INCLUDEBIN or INCLUDEFILE and it would dump the content of the required file directly into the source code in either the .CODE or .DATA section in exactly the same way as a DB sequence that is existing capacity. It would not only be convenient but it would save ML form converting DB sequences to direct binary which would be a lot faster.
I would rather see a *linker* option that lets you link in a binary file and attach a public symbol to the first byte of that file (so you could refer to the datablock from *any* language, not just an assembler).
Quote
Perhaps its time to see the end of 256 character data as well.
???
Does not Unicode, UTF-16, UTF-8, etc., all do this already?
Cheers,
Randy Hyde
Randy,
As far as an object module, I have already posted a working example that does that complete with source.
Perhaps the unicode idea would work better if it could be specified by type but the automatic conversion done by the standard API would be a good start.