>> Certainly, as long as they pay you well
The normal approach with such a client - write the code, show that it is
working (more or less), take you money and say goodbye.
Going in for support/maintenance contracts with software violating the MS’s
OS architecture is a lose. Usually lost money and bad image at the face of the client.
Actually, all you have to do is just to specify *precise* tests that your code has to pass in order to be accepted, in your contract - anything above that is just not your responsibility. Before you sign a contract, it is a good idea to provide them with a document, describing all possible solutions and analyzing all pros and cons of every solution. Let them decide what is acceptable and what is not - after all, this is their product.
After they have made their decision, you can already sign a contract, and all its terms should be
appropriate only for a given strategy that they chose. If clients decide that they don’t not mind, say, hooking, you should *explicitly* state in the project desription that your solution relies upon hooking, and, hence, is not certifiable by MSFT. Otherwise, if, at some point, they decide that they need MSFT logo, they may blame you when they discover that their product is not certifiable in principle. If your code has to be hardware-specific, you should *explicitly* state it in your contract - otherwise, they may blame you when they discover that your code does not work on other architectures. The list goes on and on…
In fact, arranging contract details properly is not as easy as it seems to be - in order to do it, one needs in-depth understanding of all technical issues involved. For example, no matter if your code is “supported” or not, you should avoid such vague phrases as “compatibility with third-party kernel-mode components” - instead, you should make it clear that you consider only those third-party components that are “properly” written (i.e. the ones that are able to pass DriverVerifier tests successfully). Otherwise, if some poorly-written third-party driver screws up your operations, you may be held responsible for this…
Going in for development with support/maintenance if you cannot influence the
architecture is even more stupid thing.
Well, actually, this is just illogical…
If you write only a part of the solution, it means that clients just purchase your code that they are
subsequently going to integrate into their product. Integration is going to be done by them and not by you, which means that theoretically they may just screw up your code. How can you take responsibility for the bugs that they may potentially introduce???
Therefore, the only situation when maintenence applies is the one when you provide them with a “black box”, so that they have no access to your code and communicate with your driver solely via IOCTLs (they should not have a chance even to register callbacks with your driver - otherwise, they may potentially screw it up). In other words, your driver is completely independent product. If this is the case…well, then you have a full control over your driver’s architecture, and, hence, don’t depend on their decisions in any possible way…
Anton Bassov