I've been using the default template in Code::Blocks to create a DLL, but when I compile, I get the undefined reference to'WinMain#16' error.
I Googled out this error and it seems that the main() I'm using is for a Window application rather than console application but there's no clear solution to this problem.
Now, do I just replace this line
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
by this
int main()?
Also, I want to insist that whatever alternative causes the least security gap and/or is the most correct solution.
Thanks!
I did encounter this same error sometime ago, just replacing some part of the code fixes it. I was using SDL in my program. This was the main function:
int main(int argc, char** argv)
I relaced it with the windows main function:
int WinMain(int argc, char** argv)
but it did end up with giving a warning for the same however the code runs.
Related
Though the title reads dll, the actual library loaded is an exe. Suppose I have an exe file testlib.exe. I need to call a function from it, let it be func(). What I am doing is:
#include <windows.h>
#include <stdio.h>
typedef char* (__stdcall *f_func)();
int main()
{
HINSTANCE hGetProcIDDLL = LoadLibrary("testlib.exe");
f_func func = (f_func)GetProcAddress(hGetProcIDDLL, "func");
printf(func());
return 0;
}
Now most of the times I run the program it gives the correct output, but in some cases (1 out of 8 for example) it gives either garbage text or values of some other variables in testlib.exe. I identify it's due to wrong memory reference but can neither explain nor solve it.
My os is windows and I'm using mingw gcc. I do not use MSVS as it does not fit well in code portability.
PS: The testlib.exe is well built and I cannot change it. It is unlikely to have any problem. I tried different versions and also it's running in other build systems well. Also it is a release build, so less hope in debugging.
UPDATE:
I've seen this question, it says that it is possible by patching the IAT table. My point is completly different. I am using a function that is neither initialised by main nor by dllmain.
Actually what I found that GetProcAddress gives right function pointer everytime. What gets messed is the return object. For example if the function in exe library is:
const char* func() {
return "Sometext";
}
then sometimes the reference to "sometext is sometimes wrong. I do suspect randomised loading but I'm not sure. I renamed the exe as dll but no change observed.
My overall goal is to use a C model inside my MATLAB code. The C model is large (over a dozen .c files, which are all run from cModel.c) and can be successfully compiled then run in the terminal by
make cModel
cModel.x startingfile.inp
as the C model is correctly built for normal C compilers.
However, MATLAB's mex function is not compiling this C code. I'm a total novice with mex and I am pulling my hair out trying to understand what the problem is.
I think (and reading some similar problems on stackoverflow backs this up) that the problem is around creating a mexFunction. My attempt currently is
/*function AA_mexWrapper.c*/
/*Include the MATLAB mex header*/
#include "mex.h"
/* The gateway function */
void mexFunction( )
{
/* Main() of the C Model*/
cModel(); /* cModel writes files. We don't care about the nonexistant returned variables*/
}
This generates the error (using mex AA_mexWrapper cModel) :
Error using mex
/Users/Filepath/ cModel.c:215:5: warning:
implicit declaration of function 'main' is invalid in C99 [-Wimplicit- function-declaration]
main(int argc, char **argv);
^
/Users/Filepath/ cModel.c:215:10: error:
expected expression
main(int argc, char **argv);
^
1 warning and 1 error generated.
What is MATLAB doing and how do I fix it? I really just need it to treat cModel.c like a normal C compiler would.
PS. I have no idea what (int argc, char **argv) are in the C code. They are totally undefined, presumably they come from the optional user input of a filename containing non-default parameters for the model.
PPS. I will need to run the C model inside matlab by pointing it to a text file containing various model options. I hope that MATLAB can deal with this, but I'm starting to have my doubts...
You cannot call an executable like a function; the name of the executable is not "exported" the way you might think.
How about a simple solution? build your executable outside MATLAB and ask MATLAB to just run it; here's a piece of code that would do that (assuming that the cModel.x is in the same folder as the script/function that calls it):
system('./cModel.x startingfile.inp');
I have a file hello.exe file path is D:\test\hello.exewhich is a simple hello world program (tested ok).
I have another program proc.c file path is D:\test\proc.c with code as follows:
#include<stdio.h>
#include<stdlib.h>
#include<windows.h>
#include<process.h>
#include<errno.h>
#include<string.h>
main(int argc,char *argv[])
{
int ret;
ret=execl("D:\\test\\hello.exe","D:\\test\\hello.exe");
if(ret==-1)
printf("%d:\t%s",ret,errno);
}
The program hangs (windows dialog says The program has stopped working)!!!
I even tried D:/test/hello.exe as param to execl(), but the same...
Where am I going wrong???
Please someone provide me the right syntax? Please prvide me example codes using various functions of process.h with MinGW under windows. Web tutorial links are acceptable as well.
Thanks a lt !!!
You have to include a library,
#include<unistd.h>
Because it is defined in this library So if you don't include this you will get AN error.
and correct your code because you have written "exec" not execl.
int main()
{
execl("D:/test/hello","D:/test/hello",0);
return 0;
}
If you compiled with warnings, you'd notice that errno is an int, but you're trying to use it with printf as a string, which means it is being used as a pointer. Memory address 0xFFFFFFF2 (or whatever the hexadecimal value of errno is) probably isn't valid.
Aside from that, you need to end your execl invocation with a NULL pointer. Otherwise the function will keep thinking it has more command line arguments, all of which are strings, until the first NULL it finds in memory or until the first invalid memory access, whichever comes first. Because copying the strings involves dereferencing a pointer, it will read the address made up of unknown bytes and attempt to dereference the pointer at that address repeatedly. If the pointer cannot be dereferenced, meaning accessing the address for reading data from it cannot be done, it will crash your program.
In the future, please compile with -Wall.
I'm starting out on SDL using CodeBlocks IDE. I got an error undefined reference to 'SDL_main'. I researched and found out that you need to have the parameters
int argc, char* args[]
in the main(). I added those and the code compiled and worked. My question is, how important are the parameters for the linker to be able to work?
Main parameters have to be there because SDL defines main internally as ......SDL_main(int argc, char *argv[])... depending on the system and does some initialization.
Just include main parameters, it doesn't matter if you're not using them.
I have following program:
#include <stdio.h>
int main(int args, char *argv[]) {
printf("%f\n", 0.99999);
printf("%e\n", 0.99999);
}
The result is:
0.009990
9.999900e-001
Why is the first number wrong? I use Windows XP, compiler "Logiciels Informatique lcc-win32 version 3.8. Compilation date: Nov 30 2012 19:38:03".
That program is correct, and its output should be:
0.999990
9.999900e-01
or something very similar to that.
(You don't use args or argv, and the usual name for the first parameter of main is argc rather than args, but neither of those is a problem that should affect your program's behavior.)
It looks like you've found a bug in your implementation, probably in the runtime library rather than in the compiler itself. My brief Google searches haven't turned up a reference to this particular bug (in fact, the top hit was this question).
I suggest contacting the maintainer of lcc-win; contact information is on the web site. A short description and a link to this question should provide enough information, at least to start.