Where do I start?

[thefox]

So, why exactly is Shiru's "runtime.lib" a file that has any purpose whatsoever, so that it needs to be referenced when listing hints for a beginner?
Why did shiru create it in the first place and why should anybody ever use it?

When I did the same for KNES, I explicitly wanted to prevent the user from using stuff from nes.h/conio.h (and maybe some others) like waitvblank(), gotox(), etc, since I didn't design the library to be compatible with them.

But you're correct that there shouldn't be much of a difference, as long as you supply your own linker configuration, startup ("crt0") code, and don't accidentally end up importing any incompatible symbols/functions from the library.

[tepples]

It could be to freeze the library at a particular version that works with your game, even if upstream makes changes that render the library subtly incompatible.

[DRW]

It could be to freeze the library at a particular version that works with your game, even if upstream makes changes that render the library subtly incompatible.

So, why not take the actual lib file then? The one that works with your game.

What I don't understand is the necessity of the following:

- I take the source code of cc65.
- I have a look what code goes into the "nes.lib". From that code, I remove a bunch of unnecessary stuff and recompile the lib.
- Now, I advertise that people should use my new, small lib instead of the bloated one that comes with cc65.
- I do this even though using the cc65 "nes.lib" does in no way increase the size of the ROM file. The linker only includes the required stuff anyway, so it doesn't matter whether I take 10 functions from a lib that contains 20 functions or if I take 10 functions from a lib that contains 200 functions. The final ROM will only include the 10 functions that I need.

So, why should anybody ever recompile the lib and publish it for other people to use or why should anybody advise to use this newly compiled lib instead of simply using the regular one that is included in the compiler suit itself?

[dougeff]

I think the purpose of a reduced library, is the compiler will give you an 'error' message if you try to do something not ideal for NES programming (I can't think of anything, currently).

Otherwise, I believe you are correct in your complaint, DRW. Only the functions used end up in the final ROM.

[calima]

I recall from my earlier mails with Shiru that he disliked the cc65 runtime, and didn't want his lib used with it.

Me, I thought just like DRW and didn't bother with the cut lib, just used the cc65 native one. If I want to use those forbidden functions, then I damn well will use them, world be damned. launchNukes(now).

[DRW]

I recall from my earlier mails with Shiru that he disliked the cc65 runtime, and didn't want his lib used with it.

Strange. It's not like he reprogrammed the stuff from the library. It's still 100 % the original cc65 code.

[lidnariq]

(This thread about neslib should be split but rainwarrior would object)

I can't speak to all of the things removed, but there's definitely an argument for not leaving two different incompatible APIs for doing PPU access (namely cc65's TGI and Shiru's neslib.s methods) ... by making TGI use cause a linking error it prevents the kind of subtle bugs that would assuredly arise from mixing the two.

[na_th_an]

Or maybe Shiru just had the stripped set of cc65 executables and the stripped down runtime.lib was included for space reasons.

Huh? What do you mean with "stripped set of cc65 executables"?

And space reasons:
If you're referring to the space on your computer's hard disk: I'm pretty sure 500 additional KB are a non-issue in the year 2016.
If you're referring to the occupied space in the NES ROM: As I said, using Shiru's lib produces exactly the same output. So, it's not like the 600 KB "nes.lib" actually puts 600 KB of data into your NES ROM while shiru's "runtime.lib" only includes 100 KB.

Some people are concerned with the incompatibilities introduced between versions of compilers, specially open sourced projects which seem somewhat active. For example, in the case of SDCC you may find that your 6 months old code refuses to compile and / or work with the latest compiler version. That's why some people (not me) opt to "freeze time" by including a barebones copy of the compiler version they are using in the project folder. That usually includes the main executables and the runtime library.

600Kb is nothing nowadays, but if you have quite a bunch of project folders (think about me: I have around 100 project folder for several platforms) everything adds up, more so if you use google drive or the likes (In my case, I'm struggling with a full Google Drive folder right now ).

That's what I meant. That could be the case, I don't know.

Seriously, I couldn't care less

[DRW]

I can't speak to all of the things removed, but there's definitely an argument for not leaving two different incompatible APIs for doing PPU access (namely cc65's TGI and Shiru's neslib.s methods) ... by making TGI use cause a linking error it prevents the kind of subtle bugs that would assuredly arise from mixing the two.

Hmm. But if I don't want to use certain functions, then I simply don't use/import/include them. And if I cannot distinguish between them, then maybe I shouldn't program that stuff in the first place.

I mean, that's like if I altered the standard C header files to remove the function declaration of memcpy, so that I don't accidentally use it because I have my own CopyArray function that's shorter since the size variable is only one byte instead of size_t.

Some people are concerned with the incompatibilities introduced between versions of compilers, specially open sourced projects which seem somewhat active. For example, in the case of SDCC you may find that your 6 months old code refuses to compile and / or work with the latest compiler version. That's why some people (not me) opt to "freeze time" by including a barebones copy of the compiler version they are using in the project folder. That usually includes the main executables and the runtime library.

I would understand this. But shiru didn't include the compiler. He included just the runtime.
Which means:
If the compiler becomes incompatible, then shiru's lib won't help you anyway.
And if the newer compiler still works, then shiru's lib can potentially work against you because it might be possible that you get an error because you link the outdated runtime library instead of the one that belongs to the compiler.

There's no reason I can think of where compiling your own runtime and shipping it will produce less incompatibility.

600Kb is nothing nowadays, but if you have quite a bunch of project folders (think about me: I have around 100 project folder for several platforms) everything adds up, more so if you use google drive or the likes (In my case, I'm struggling with a full Google Drive folder right now ).

Well, if you have to store the whole compiler for each project anyway, then the exe files will occupy the majority of space. Arbitrarily recompiling one small file would be pretty random here.

Besides, my suggestions for you: Put the various compilers in a central location and let the project reference the compiler that it belongs to.
Even though you have 100 projects that use maybe 10 different compiler versions, you don't need to store the correct compiler version in each project, i.e. 100 times. Just put all 10 compilers somewhere and make sure that the project uses the right one, by referencing it via version number or build date.

[lidnariq]

I mean, that's like if I altered the standard C header files to remove the function declaration of memcpy, so that I don't accidentally use it because I have my own CopyArray function that's shorter since the size variable is only one byte instead of size_t.

No it's not, because using both memcpy and CopyArray in the same program won't cause bugs.

It has more similarity to using non-thread-safe functions (e.g. rand, gethostbyname, qsort) in multiple threads.

[na_th_an]

Even though you have 100 projects that use maybe 10 different compiler versions, you don't need to store the correct compiler version in each project, i.e. 100 times. Just put all 10 compilers somewhere and make sure that the project uses the right one, by referencing it via version number or build date.

That's the way I work, indeed (I keep the latest 2.13 and 2.15 versions of cc65 in every computer I use for developing, for example), but I know people who actually add the compiler files in each project folder.