I can't speak directly to managed code since I've never worked with it; however, generating an exception as appears to be the model sounds like the right thing to do. In the context of unmanaged code (I believe it is the unmanaged dbdata DLL that is dynamically loading the likewise unmanaged dblgen DLL in this case), that message generally represents a mis-installation of the product and the message is very helpful to the developer who sees it. It generally should not be seen in a deployed application but, on the off-chance that the message is displayed in the field -- even for unmanaged apps, then I agree that displaying a message box is not a very embedding-friendly thing to do. A product enhancement request should be made though I'm happy to do so from within Sybase. For what it is worth, until the language DLL is loaded you won't be able to get useful error messages about anything else that goes wrong.

Of course, I can't explain why the DLL wasn't loaded if it was in the current directory and that's the real problem here. We definitely look in the current directory as well as the same directory as the DLL that is doing the loading, the same directory as the executable that is running plus various other directories where the product might be installed as indicated by environment variables and registry settings. Perhaps some crazy restrictions are imposed by the managed environment? If DLLs must be copied into some other directory just to be loaded by managed code then I hope the developers of the driver remembered to copy the DLLs for all of the other languages too. I'll need to check that with them. Perhaps the problem is that the directory containing dblgen DLL isn't actually the current directory as the author claims and since we copied dbdata to a temporary location then we have no idea where to find dblgen unless the environment or registry is configured correctly. If the DLL is correctly installed and can't be loaded then a bug report should made so that tech support can help the developer find out what is going wrong on their system and/or get a fix implemented.

I would also add that displaying message boxes for errors on Windows is quite normal too. The LoadLibrary() call itself defaults to displaying a message box if a library cannot be loaded unless those message boxes are disabled via the SetErrorMode() call. Similarly, a message box is displayed by the OS when an executable or DLL is loaded that has a static reference to another DLL that cannot be found. Perhaps the displaying of the SQLAnywhere message box should be controlled by the current Windows error mode too.

In summary, this is not really a WTF in my books but the behaviour could be improved for embedability and there could be a bug or two lurking in there. A bug report should definitely be made if the developer can't get the language resource DLL to load correctly on a properly installed system.

An open-letter rant, um, constructive criticism isn't the nicest way to get a change request but we're here to help and we'll definitely take good suggestions into consideration however they come to us.