how to create and distribute executable subroutines

DLL stands for dynamically linked library - a concept supported in Windows where the program and the library gets connected to each other first when the program starts.

This isn't applicable to a 8051 processor or for most smaller embedded systems. You need to build a static library that your customer makes use of directly when they link their own application.

And you need to distribute both the library (built with the relevant compiler options like for example the memory model) and the header files describing the variables/functions in your library.

I don't use the C51 tool set, but I would hope this link is relevant for C51 too.

www.keil.com/.../uv4_ca_createlibraryfile.htm

Obviously, you shouldn't go this route unless your code or the API really represents significant money. It's a vulnerability for the customers to have to use a library they don't have the source code for, and where they don't know how long they can get support. And having just the library will hamper they ability to debug their applications.

Most people who wants to ship libraries instead of code has just arbitrarily assumed that their code is so very unique that it just has to be protected. And most of them are wrong. So make sure your specific code really do need to be semi-protected (a skilled customer will still be able to reverse-engineer how your code interfaces with the hardware).

DLL stands for dynamically linked library - a concept supported in Windows where the program and the library gets connected to each other first when the program starts.

This isn't applicable to a 8051 processor or for most smaller embedded systems. You need to build a static library that your customer makes use of directly when they link their own application.

And you need to distribute both the library (built with the relevant compiler options like for example the memory model) and the header files describing the variables/functions in your library.

I don't use the C51 tool set, but I would hope this link is relevant for C51 too.

www.keil.com/.../uv4_ca_createlibraryfile.htm

Obviously, you shouldn't go this route unless your code or the API really represents significant money. It's a vulnerability for the customers to have to use a library they don't have the source code for, and where they don't know how long they can get support. And having just the library will hamper they ability to debug their applications.

Most people who wants to ship libraries instead of code has just arbitrarily assumed that their code is so very unique that it just has to be protected. And most of them are wrong. So make sure your specific code really do need to be semi-protected (a skilled customer will still be able to reverse-engineer how your code interfaces with the hardware).

Thanks for the reply.
The last part was especially. important.
AS software programmers we do get carried away about the holiness of our code..
So if they can reverse engineer it, maybe it is not worth all that extra effort.
Thanks.
Bhal

The 'normal' for delivering 'canned' code is a library and a .h file. This does not give you a whole lot of protection from determined code thieves, but it protect you from the casusl thief. Since "everybody knows better than you how to code" what is important is that it protect you from having to discuss with a user "why didn't you use a state machine instead of if/if else" or some such, which you will end up doing if you release source.

Erik