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
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
Thanks for any response.
Please log in or register to post a reply.
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…
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.
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
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.
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
calls around to see if something is going wrong?
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.
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.