vilem_otte at January 21st, 2012 18:10 — #1
Well actually not. We have quite large project in development (after \~3 months of hard work, we had just Linux branch before), we got it running on Linux (our main target platform), FreeBSD and OpenBSD ... and the largest one awaits, the Microsoft Windows (and if we get it working there, we might as well target Mac if our patience won't die on Microsoft). We used gcc and tried to compile it with clang without any issues.
So, we heavily died with trying to compile it under MSVC and WinApi. Actually we can compile it, but as soon as we call strstr function, it dies screaming some issue with msvcr100.dll
So I'd like to ask, has anyone actually met similar issue? How can we solve it (or how can we drop MSVCR library out of specs, is it even possible)?
Thanks for any response.
vilem_otte at January 21st, 2012 18:29 — #2
Okay, more specific issue - it does actually scream only (or firstly) in graphics subsystem, when we call strstr on list of OpenGL extensions and extension name, wonder why...
reedbeta at January 21st, 2012 18:40 — #3
Could it be a character encoding issue? If the OpenGL string is being returned in one character set and strstr is expecting another, it's conceivable it could get confused and run off the end of the string causing an access violation, or something like that.
vilem_otte at January 21st, 2012 18:54 — #4
I'm just about to run it through debugger again right now ... I'll take a look whether the character sets aren't different. Right now (e.g. when I ran it through debugger for the last time) I discovered it is directly related to OpenGL extensions, or GL context creation (or it seems to be related to them).
Okay, got more info ...:
I wonder why I get NULL pointer when getting OpenGL extensions list through standard way glGetString(GL_EXTENSIONS); so right now I know where the first issue is (hope there isn't any second). Huh... so it actually isn't problem in strstr, but more like that I don't have the list to perform compare.
Anyway I still don't get why glGetString(GL_EXTENSIONS); returns NULL pointer... huh. Could it be wrong glext, or issue while creating OpenGL context?
And even more info ...:
Creating windows OpenGL window as specified on MSDN. The funny thing is, I actually get Device context = -620687535 (could be good adress, but I think it should be positive, not?), but rendering context is probably invalid (65536 - or is it valid?). Any more info on this?
I finally managed to run the application and it "works" (that Device context and Rendering context was alright ... ). Reed, you were right it was due to different character sets (Not in the strstr, but during window creation). Thanks. I seriously need to get some more Windows and WinApi programming again, after so long time in Linux.
reedbeta at January 21st, 2012 19:27 — #5
The device context is probably a pointer that the debugger is misinterpreting as an int, hence the weird-looking number. I'm not sure about the rendering context. But glGetString giving you NULL is usually a sign of no valid OpenGL context set up. Did you make the context current with wglMakeCurrent? Are you checking the return codes of all the setup functions? Try sprinkling some GetLastError calls around to see if something is going wrong?
vilem_otte at January 21st, 2012 19:43 — #6
Btw. replied in previous post with edit - it was problem during window creating, but even before wglMakeCurrent (which actually returned weird values). I did something wrong when creating window (I've been pushing wrong character set in them, and that resulted in so famous "undefined behaviour" = crash, sooner or later).
Although it is really strange that it pointed issue in strstr a lot further in program, when it should (or shouldn't?) die when window was created. So it seems that I got it running on Windows with just a bit more pain than when doing BSD version.
aticatac at January 23rd, 2012 11:20 — #7
Just a typical case of not knowing the system (windows) you program for good enough. So people always first blame it on system and enviroments (tools) until they detect their mistake.