From: Henrik C. <he...@cl...> - 2000-02-18 08:49:54
|
Hi there! Is there anyone out there?? Henke |
From: <r-l...@ui...> - 2008-03-17 16:00:05
|
Dear freeglut developers, A simple addition in frfeeglut_main.c: When the monitor goes into sleep mode under Windows, one gets a recurring error in debug mode, freeglut (af?): Unknown wParam type 0xf170 The hex code, the win32 call type (wparam), is: const int SC_MONITORPOWER = 0xF170. This is a two-line fix in the source when it is next revised and will help some of us avoid wildly scrolling console windows when we leave the screen for a while. Ron Larkin |
From: Paul M. <pm...@sk...> - 2009-05-02 20:36:34
|
(Sorry, Sven. Reposting this to the list.) > Now to the more serious issues: When you download Nate's OpenGL Tutors > (http://www.xmission.com/~nate/tutors.html) and replace its glut32.dll > with our renamed freeglut.dll, the tutorial don't work! I am currently > sitting a Linux box, but IIRC, the problem was that the executables do > not find the GLUT API entry points in our DLL. A quick look with > objdump shows that our DLL entries have a leading underscore and "@XY" > suffixes, while Nate's DLL contains the plain names. Somehow this > looks like a problem with the calling convention, but without tools > like dumpbin etc., which I currently do not have, this is hard to say. > Could somebody please have a look at this? Our DLL should really be > a drop-in replacement, but apparently it is not... > > I'd vote for not releasing 2.6.0 until we have figured out the last problem. How important is binary compatibility with Nate's DLLs? Has freeglut supported this in the past? All the symbols in freeglut built with VC6 have a single leading underbar. In Nate's DLL, most all of the entry points have no leading underbar, but there are a few mysterious symbols defined with two and three leading underbars. One of the symbols is "__glutInitWithExit", and this is the symbol I get in the error dialog when I try to drop my DLL in place of his and run a tutor. Freeglut does not define a symbol like with, with or without underbars. My foggy memory recalls that this symbol in Nate's library has some non-trivial history relating to how GLUT apps link against the c-runtime exit() symbol, but I don't recall all the details. I could track down eliminating the underbars in our symbols, but unless we intend to start supporting a __glutInitWithExit entry point, this would be moot. If freeglut has never supported a release that is binary-compatible with Nate's, then I see no reason to start doing so now and hold up this release even longer. Regardless, I have downloaded Nate's source and will take a look so that I can understand the issues further. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com <http://www.skew-matrix.com/> +1 303 859 9466 |
From: Sven P. <Sve...@ae...> - 2009-05-03 10:06:06
|
Am Samstag, 2. Mai 2009 22:09:58 schrieb Paul Martz: > How important is binary compatibility with Nate's DLLs? Has freeglut > supported this in the past? [...] I always thought that freeglut was supposed to be binary compatible to GLUT. We even do some sill^H^H^H interesting things regarding fonts because of this, see e.g. freeglut_std.h, including a comment. So from my point of view it is important. > One of the symbols is "__glutInitWithExit", and this is the symbol I get in > the error dialog when I try to drop my DLL in place of his and run a tutor. > Freeglut does not define a symbol like with, with or without underbars. My > foggy memory recalls that this symbol in Nate's library has some > non-trivial history relating to how GLUT apps link against the c-runtime > exit() symbol, but I don't recall all the details. Good point! Looking into Mesa's GLUT header, one can see the reason for this hack: ----------------------------------------------------------------------------- [...] /* Win32 has an annoying issue where there are multiple C run-time libraries (CRTs). If the executable is linked with a different CRT from the GLUT DLL, the GLUT DLL will not share the same CRT static data seen by the executable. In particular, atexit callbacks registered in the executable will not be called if GLUT calls its (different) exit routine). GLUT is typically built with the "/MD" option (the CRT with multithreading DLL support), but the Visual C++ linker default is "/ML" (the single threaded CRT). One workaround to this issue is requiring users to always link with the same CRT as GLUT is compiled with. That requires users supply a non-standard option. GLUT 3.7 has its own built-in workaround where the executable's "exit" function pointer is covertly passed to GLUT. GLUT then calls the executable's exit function pointer to ensure that any "atexit" calls registered by the application are called if GLUT needs to exit. Note that the __glut*WithExit routines should NEVER be called directly. To avoid the atexit workaround, #define GLUT_DISABLE_ATEXIT_HACK. */ [...] GLUTAPI void GLUTAPIENTRY glutInit(int *argcp, char **argv); #if defined(_WIN32) && !defined(GLUT_DISABLE_ATEXIT_HACK) GLUTAPI void GLUTAPIENTRY __glutInitWithExit(int *argcp, char **argv, void (__cdecl *exitfunc)(int)); #ifndef GLUT_BUILDING_LIB static void GLUTAPIENTRY glutInit_ATEXIT_HACK(int *argcp, char **argv) { __glutInitWithExit(argcp, argv, exit); } #define glutInit glutInit_ATEXIT_HACK #endif #endif [...] ----------------------------------------------------------------------------- Ugly as it is, I think we should mirror stuff in freeglut. > I could track down eliminating the underbars in our symbols, That would be great. > but unless we > intend to start supporting a __glutInitWithExit entry point, this would be > moot. If freeglut has never supported a release that is binary-compatible > with Nate's, then I see no reason to start doing so now and hold up this > release even longer. [...] There is another option: Ignore this issue for now and release 2.6.0 with a fat warning that it is *not* binary compatible with GLUT, and do a 2.6.1 release soon, i.e. within weeks. Cheers, S. |
From: ROBERT H. <how...@sb...> - 2011-11-08 14:50:45
|
Please remove me from the Freeglut mailing list. Thanks, Benton Howell |
From: John T. <nu...@me...> - 2011-11-08 18:42:30
|
On Tue, Nov 08, 2011 at 06:50:38AM -0800, ROBERT HOWELL wrote: > Please remove me from the Freeglut mailing list. Thanks, > Benton Howell Just follow the url at the bottom of every email on this list and you will be able to unsubscribe yourself. Nobody has to do it for you. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Pawel W. O. <ol...@so...> - 2000-02-20 07:50:28
|
> Henrik Carlsson wrote: > > Hi there! > > Is there anyone out there?? > > Henke > Yeah, I'm getting back to work on freeglut next week. -- Pawel W. Olszta (olszta at promail.pl) ... Visit the freeglut project site: http://www.promail.pl/~olszta ............. http://freeglut.sourceforge.net |
From: Adam H. <ad...@ne...> - 2000-02-20 21:53:38
|
On Fri, Feb 18, 2000 at 09:46:01AM +0100, Henrik Carlsson wrote: > Hi there! > > Is there anyone out there?? Yo. -- Adam Haberlach |BeOS: it's nothing that somebody hasn't done before. ad...@ne... | Until now, something that nobody has done right. http://www.newsnipple.com/ | --Me |