Just write it in a dialect of C that is compatible with cc65. That means not using any specific extensions and, usually, limiting yourself to something like c89 syntax.

Usually you can get the same code working between cc65 and something like GCC and even sdcc, as long as you are careful in using any specific implementation formats.

At the end of the day C is C, regardless of compiler. You shouldn't have to 'port' your code between compilers if written sensibly. If you really need to use compiler specific implementation for certain bits, then use your preprocessor directives #ifdef and the like to switch on bits of the code for your specific platforms.

I've not written much compression code, but plenty of multi platform things all the way from MSX to PC-98 or X68000 and have never had to have two completely different codebases for non-hardware dependent code (ie anything not directly hitting framebuffer or sprites).

I thank you for your input. For efficiency, I'm using not only platform-specific code but support written for them. Don't worry: I know about #ifdef. 😀 So, if I want to port it, I have to do some translation. So, should I do that? If so, what is the most efficient way to print text on different DOS-based and DOS-target C compilers? BTW, I have libraries for some cc65 targets valled *simpleio. They are replacements for the printf() function and other similar functions that are more efficient than such. Unfortunately, they are cc65-specific. I want to port them to DOS C as well but need some more information first, such as how to handle parameters of __fastcall assembler functions and perform 32-bit multiplication and division.

I would guess that in most cases, there's not going to be much call for something like that in DOS since memory and storage on most DOS platforms are really not going to be a limiting factor, even in real-mode without any XMS or EMS you've still got a frankly 'enormous' 640kb to use.

Okay. Thank you.

I assume the benefit of this library is that if you have a lot of static strings, the size of the executable on disk and in memory will be smaller? I imagine you'd need a lot of static strings to make it worth the presumably small cost of the extra code to decompress plus the much larger cost of a preprocessing step, particular if the preprocessing is manual.

For DOS at least, I think often when someone has that much text that it would be useful to compress it, they put that into a separate file, and then you can probably fairly easily compress it using a standard tool.

Also, for strings in an executable file, you could use LZEXE or something to compress the entire executable (not just the strings) to bring down the size of the binary, and as megatron said, the size of the in-memory program is probably not such a big deal in DOS.

Perhaps it'd still be nice to reduce the size of the executable in memory if you're aiming to fit all your data - or even all your code and your data - into a single segment? But again, I think those sorts of things would often be solved by putting the text into a separate file - possibly even not compressed - and only loading the text when it's needed.

I can't see myself wanting to use something like this, but I'm probably not in your target audience as I don't often have to worry about the size of my programs.

doshea: I thank you for your input. As it stands, printtok requires manual compression, but I'm working on a better version that offers more and better compression and the ability to compress the strings for you. You're right, though: DOS has enough memory to not need this.