Hi, I've made a few FASM-related topics on some other forum, and I didn't get a satisfactory answer. Could you reply to them please?
https://www.theflatearthsociety.org/forum/index.php?topic=67453.0
https://www.theflatearthsociety.org/forum/index.php?topic=67449.0
https://www.theflatearthsociety.org/forum/index.php?topic=64277.0

For the "bus error" I would assume that you are trying to write to memory marked as read-only and/or execute-only. Try moving your data into a writeable segment. I would guess that strings are placed into "constant" memory by HLLs so if you try to write to them your program will crash.

Assuming HLL means "High level language", I wasn't using a high-level language, I was writing directly in the assembly language. And how exactly would you mark a part of a memory as "constant"? I've always thought that it's just the compiler keeping track of what's constant and what's a true variable.

You can use the paging system to mark memory readable, writeable, executeable or non-existent. Some compilers use this to place constants and variables in certain places within the memory space.

So, what exactly do I have to add to my source code to be able to, let's say, directly modify the "string" in the 2nd example (without having to use the stack)? I've seen, by disassembling, that the compilers I use all use the stack to keep the variables. I wonder why.
I didn't know that about the paging system. So, DOS doesn't use it, as I can see from the 5th example, right?

For source code in fasm you can simply mark the segment as writeable.

Thanks, that helps!
Anyway, do you have some experience with disassemblers? Can you help me with the problem with them I described on the third link? Thanks in advance.

You will have to specify which disassemblers you are using. Some disassemblers know about the file formats and will make sense of the code while others are simply raw binary-to-source engines and show lots of useless things that are actually file headers and other non-code parts of executable files.

I am not sure I understand what you are asking. I did specify them. I was using lldb, the debugger of the LLVM, on an x64 processor structure and Darwin OS, and FreeDOS DEBUG in DosBox (which simulates DOS and x86). Both lldb and FreeDOS DEBUG are, among other things, disassemblers. Isn't that enough?

Another thing to consider is that if you are using an HLL to create the executable then likely you will have to deal with the extra support wrappers and calling overheads that some compilers insert.

The easiest type of file for disassemblers to deal with are DOS .com programs. These have no file headers, just raw binary code and data.

Universe, programs compiled for different platform and/or using different compiling techniques do generate different binaries. Also emulated environment may introduce their own layers and abstractions that modify the generated binaries. In this case you need to manually point your debugger / disassembler to the correct entry point for each. FreeDos generates / expects either MZ or COM 16-bit format or other extended modes. Clang on Mac Air (something I am not familiar with) have their own format, probably mach-o, elf or things like that. Common sense says, they do produce different binaries or at least read the same binaries differently.

Yeah, System, that was also my guess.

https://www.theflatearthsociety.org/forum/index.php?topic=64277.msg1772117#msg1772117

Don't use FD Debug for disassembling Mach-O, that's the wrong tool for the job.

Use GNU Objdump (built for Mac OS X support) or BIEW/BEYE or Agner's OBJCONV or .... I'm not sure NASM's NDISASM understands anything besides raw binary, so you may have to tell it to skip directly to the file offset where code starts (assuming it's contiguous). Also, what about distorm or Hopper or IDA or OTX?

In other words, there are probably better tools (for Mac OS X / Mach-O) than FD Debug.

Oh, I see!
So, what do you think about my proof that FASM preptocessor is Turing-complete? Do you think it's correct? If no, why not?