If you are linking for 64bits the entry point for dll should be _DllMainCRTStartup (undecorated entry point). If you get this error probably there is a error in linker switches because it seems that you are trying to use 64 bits objects in a 32bits link.
It is not very clear in which part of your project you're getting the error: compiling the console exe or one of the DLL?
A very simple and realistically non-worthwhile implementation is simple. Your malloc calls new with an byte array. Then your free, which you would also implement would use delete to delete the array.
If you want a learning experience however then you should do the following in the specified order.
1. Learn what stack and list are and how to implement them.
2. Specifically learn how to implement them using sequential memory and not just pointers.
3. Learn how malloc is generally implemented. You will need substantial understanding of 1/2 to understand this.
4. Implement your own heap management. (Which you will understand after doing 1/2/3.)
There are no limitations to support different types of databases in one application. The application wizard only prepares the project to support a specific database interface. Support for other interfaces can be added later manually.
Create two new empty projects with support for different database interfaces. Then choose one as your project and add the necessary definitions from the created source files of the other project by comparing the files.
Thanks for reply.
Since wizard can relief my work. I just think is it possible to select both ODBC and OLEDB by using wizard.
If it is not possible, I have to implement the code myself.
That's hell a lot of work
Note that reading even a trivial excel file in an application can be a difficult task.
Once you have read the data the user interface and writing to a database is easier because there are more sources that one can learn from.
But as you can see this is much more code and it is insecure without checking for buffer overflows (which adds more code).
If you don't need the data to be in text format (e.g. only loaded by your application), it might be better to write the data to a binary file. That solves also the problem of inaccuracies when converting floating point values to text and back again later.
FILE *f = fopen(fileName, "wb");
fwrite(&newForce.x, sizeof(newForce.x), 1, f);
// Write other items here
Reading is then done in a similar way:
FILE *f = fopen(fileName, "rb");
fread(&newForce.x, sizeof(newForce.x), 1, f);
// Read other items here