Question

I am using an older version of SQL Server (2000). I do not want my users to have permission to run master.dbo.xp_cmdshell. I am trying to create a custom DLL that I can use to create my own extended stored procedure that I grant users permission to run – one that is hard-coded to execute a specific batch file that users need to be able to run on demand.

I’m using Visual Studio 2010 to create the DLL. Here is my header file stdafx.h:

#define WIN32_LEAN_AND_MEAN 

#include <windows.h>
#include <iostream>

#ifndef INDLL_H
    #define INDLL_H

    #ifdef EXPORTING_DLL
        extern __declspec(dllexport) void HelloWorld() ;
    #else
        extern __declspec(dllimport) void HelloWorld() ;
    #endif
#endif

and here is my main file dllmain.cpp:

#include "stdafx.h"
#define EXPORTING_DLL

BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                   LPVOID lpReserved)
{ return TRUE; }

void HelloWorld() {
    system("f:\\bin\\batchfilename.bat");
}

When I try to debug this project, I see that the build succeeds, but I get an error “Unable to start program: <path to compiled dll>.” Do you think this DLL will work, and if so, how can I test it to see for myself if it works?

Answer 1

OK, After many hours of Googling, I successfully compiled a DLL to add as a SQL Server 2000 extended stored procedure. I’m going to share it here, since it’s just a compilation of things I’ve put together from my Googling. (I used Visual Studio 2010). I’m not going to post everything – I started by creating a new project in Visual Studio and choosing Win32 Console Application, then Next, then DLL. It creates a few header files and other files for you. Some of them I didn’t see any need for. And some of the header files you must add to the project manually. But here’s my main .cpp code:

#include "stdafx.h"         
#include "srv.h"   //Must get from C:\Program Files (x86)\Microsoft SQL Server\80\Tools\DevTools\Include            
#include "shellapi.h"  //need for ShellExecute          
#include "string"   //needed for std:string         
#include <sys/stat.h>  //need for stat in fileExists function below         

#define DLL_FUNC extern "C" __declspec (dllexport)          

__declspec(dllexport) ULONG __GetXpVersion() {          
   return ODS_VERSION;          
}           

bool fileExists(const std::string& filename) {          
    struct stat buf;            
    if (stat(filename.c_str(), &buf) != -1)         
    { return true; }            
    return false;           
}           

DLL_FUNC int __stdcall RunPP() {            
    if (fileExists("C:\\FileOnServer\\execute.bat")) {      
        ShellExecute(NULL,TEXT("open"), TEXT("C:\\FileOnServer\\execute.bat"), NULL, NULL,SW_SHOWNORMAL);       
        return 0;   
    } else {        
        MessageBox(HWND_DESKTOP, TEXT("File not found."), TEXT("Message"), MB_OK);  
        return 1;   
    }       
}           

I learned that you can test out this DLL using rundll32 (rundll32 yourdllname.dll,functionname {no space after comma}) from the command line, but only if you include a .def file in your project. My def file is

LIBRARY
EXPORTS
RunPP

Also, as the documentation states, I tried to add a reference to Opends60.lib in Project > Properties… > Linker > Input > Additional Dependencies, but it looks like it got removed at some point.

For those of you as newbie as I am, I had to learn a lot of things in the project’s Property pages like switching C/C++ > Code Generation > Runtime Library to /MD. Also learning how to compile in Release mode, where to locate the resulting .dll file, etc.

Then when moving the compiled DLL to my SQL Server machine (Win2003R2), I had to install the VC++ 2010 Redistributable for it to run. Then I copied the DLL to C:\Program Files\Microsoft SQL Server\MSSQL\Binn on my machine (same place where xp_cmdShell extended stored procedure’s DLL was), and then ran sp_addextendedproc according to the documentation to register it as an available extended stored procedure in the master database. Then granting privileges for users to execute it, etc.

I know all this is an old technology. I should just upgrade my SQL Server version. But maybe this will help someone else.