Recent posts

[_MSC_VER 1500]

#21

Announcements / Re: Release Candidate #2 for v...

Last post by TimoVJL - March 31, 2026, 11:02:19 AM

Some C-code needs _MSC_VER 1500 just for using intrin.h
A new define won't help.
One test was 7Zip code

#22

ARM64 discussions / Re: Not frustrated enough? Too...

Last post by Pelle - March 31, 2026, 10:18:44 AM

Thanks for the ARM64 example. I don't have a computer with an ARM processor, so not easy to the test sample. Thanks for maintaining Poasm. Yes, the C version is shorter and is looking better.

I have seen some hints on the web that Windows 11 (on X64) may be able to emulate ARM64 code (not just using the weird ARM64EC mode). I can't verify this myself since my only Windows 11 machine right now is a laptop with an ARM64 processor.

#23

Announcements / Re: Release Candidate #2 for v...

Last post by Pelle - March 31, 2026, 10:07:18 AM

Release Candidate #2 for version 14.00 work on Windows 7 Sp1 64-bit, many thanks.

Thanks for the info! Good to know...

#24

Announcements / Re: Release Candidate #2 for v...

Last post by Pelle - March 31, 2026, 10:06:30 AM

Turns out to be more than just the one file.  I checked the Option you mentioned above it was set to UTF-8.  Most files in the program were ANSI, including file.c, a few newer additions were UTF-8.

Sounds like what I stumbled on yesterday, by dumb luck. When debugging a totally unrelated case, the debugger complained about "invalid characters" when trying to load a source file (using the same load function as the source editor). On my machine it boiled down to double quotes (code 34 vs 147).

The revised sequence when loading is now:
1) If the text file begins with a BOM for UTF32LE, UTF32BE, UTF8, UTF16LE, UTF16BE: pass it on as encoded this way (for later processing or "sorry, bad format").
2) If the text file is longer than 32 bytes (for technical reasons), scan the whole file (memory mapped) and check for UTF-8 special encoding. If not invalid, and at least one 'extended' character: pass it on as UTF-8 encoded (no BOM).
3) If "Options" -> "Source editor" -> "Default encoding, source files" is set to UTF-8, scan the whole file (memory mapped) and check for 7-bit ASCII encoding. If not invalid (code above 127, or unwanted control char): pass it on as UTF-8 encoded (no BOM).
4) Pass it on as ANSI encoded (whatever that means, in different parts of the world).

This works on my machine. I really hope this is it, because it's getting complicated...

I don't want to upload yet another Release Candidate just for this. If there is no major breaking bug this will hopefully be in the final version (otherwise Release Candidate 3).

#25

Announcements / Re: Release Candidate #2 for v...

Last post by Vortex - March 30, 2026, 11:25:39 PM

Hi Pelle,

Release Candidate #2 for version 14.00 work on Windows 7 Sp1 64-bit, many thanks.

#26

ARM64 discussions / Re: Not frustrated enough? Too...

Last post by Vortex - March 30, 2026, 09:09:29 PM

Hi Pelle,

Thanks for the ARM64 example. I don't have a computer with an ARM processor, so not easy to the test sample. Thanks for maintaining Poasm. Yes, the C version is shorter and is looking better.

#27

Announcements / Re: Release Candidate #2 for v...

Last post by John Z - March 30, 2026, 02:36:03 PM

2) What is your setting for "Options" -> "Source editor" -> "Default encoding, source files" ?

Turns out to be more than just the one file.  I checked the Option you mentioned above it was set to UTF-8.  Most files in the program were ANSI, including file.c, a few newer additions were UTF-8.  I toggled the default to ANSI and the file(s) loaded into the editor just fine so did all the others I had just found were also indicating error.

I then just toggled the setting back to UTF-8 and everything was still working, even though I did not re-save any file.  But they are all marked UTF-8 (No BOM) now in the editor.

Checked an archived version and it was repeatable.  Easy fix toggle the Option.  Going to check a few older files (ANSI) for this issue.

John Z

#28

Announcements / Re: Release Candidate #2 for v...

Last post by Pelle - March 30, 2026, 01:36:57 PM

The only different thing I see is with a single C file that was 'OK' under V13 but is reported as having illegal character(s) under V14.  I could not find any bad character(s) and other text editors did not show or complain either.  Finally I just used TextPad to re-save the file as UTF-8, with BOM, then it was acceptable to V14, nothing looked different...

1) Can I somehow look at the "broken" file ?
2) What is your setting for "Options" -> "Source editor" -> "Default encoding, source files" ?

Perhaps a future enhancement could report the byte position of the 1st offending character so it would be easier to locate and correct.

Properly formed text files should always load. Malformed text files should be uncommon enough that my time is better spent on more important tasks.

#29

Announcements / Re: Release Candidate #2 for v...

Last post by Pelle - March 30, 2026, 01:20:48 PM

Thanks,
that i can still use my an old PC full of an old C-code for testing new version.

Thanks. No problem. 

#30

Announcements / Re: Release Candidate #2 for v...

Last post by John Z - March 30, 2026, 12:46:25 PM

All looking good on my various programs, and other test files.

The only different thing I see is with a single C file that was 'OK' under V13 but is reported as having illegal character(s) under V14.  I could not find any bad character(s) and other text editors did not show or complain either.  Finally I just used TextPad to re-save the file as UTF-8, with BOM, then it was acceptable to V14, nothing looked different...

Perhaps a future enhancement could report the byte position of the 1st offending character so it would be easier to locate and correct.

All good.

John Z