While we''re on the topic, what is a "vararg" function?
A function taking a variable number of arguments such as printf.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan
what is __stdcall?
Author
So it''s just a function that''s been overloaded one or more times? Or is there something special about it?
Just so I don''t have to start another thread, what calling convention does opengl32.dll use? I''m thinking it''s stdcall b/c I disassembled a few calls and it doesn''t appear that the stack is being cleaned up by the caller. I need to know b/c i''m starting opengl with nasm where the calling conventions aren''t so transparent.
quote:Original post by temp_ie_cant_thinkof_name
Just so I don''t have to start another thread, what calling convention does opengl32.dll use?
Either check the header file, or look at the way the symbol names are mangled - MSVC mangles differently for each calling convention, check the documentation for details.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan
quote:Original post by serratemplar
So it''s just a function that''s been overloaded one or more times? Or is there something special about it?
No, it''s the same single function (there is no overloading in C, and variadic functions are a C concept), but it can accept any number of arguments. There are macros that will let you retrieve them one by one from the stack. The parameter order ensures that the first argument is at the top of the stack, which enables you to use it to figure out exactly how many arguments there are (e.g. printf counts the number of %whatever placeholders there are in the format strings).
As a word of warning before you become overenthusiastic, variadic functions do not digest C++ objects well.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan
quote:Original post by temp_ie_cant_thinkof_name
Just so I don''t have to start another thread, what calling convention does opengl32.dll use?
This isn''t that hard to figure out. If you check the GL.h header with MSVC, you see that all the functions are defined as APIENTRY functions. If you grep the windows headers you can find that APIENTRY is a #define for FAR __stdcall.
Wow, that was quick. Thanks for the help. Alas, I have one more quick question. The FAR word in your post SiCrane; does that have any significance in assembly? B/c I beleive a far call is just a call to an offset that''s possibly in another segment so 48 bits are req''d and CS may need to be changed... Or is it something entirely different in MSVC?
If you do a grep for FAR in the windows headers, you''ll find that FAR is #defined to be nothing under WIN32. If you happen to be on a non-WIN32 system, FAR may be defined as _far, for example IA64. I''m not an IA64 programmer, so I have no practical experience if this is actually the case.
LOL, I remember this.
Back in the days of old (non win32) when we had 16bit memory systems we used a thing called dos.
Also we had Win16 (eg win1.1 to win3.1, and windows for work groups - aka nt, and os2 and so on).
Anyway, we could define memory as normal or huge.
Huge was when you wanted an ENOURMOUS amount of data in your stack space.
eg, you can''t stick much data into a 64K block of memory, but back then we had to.
If you wanted more than 64K, you defined it as HUGE.
Now, normally you would have lets say:
char *neardata;
you could set it with malloc();
if you wanted lots of data it was something like
huge char *fardata();
and you created it with farmalloc();
They had defines as NEAR and FAR.
FAR being huge, and NEAR being normal.
Hope that helped.
If not - from borland.
Back in the days of old (non win32) when we had 16bit memory systems we used a thing called dos.
Also we had Win16 (eg win1.1 to win3.1, and windows for work groups - aka nt, and os2 and so on).
Anyway, we could define memory as normal or huge.
Huge was when you wanted an ENOURMOUS amount of data in your stack space.
eg, you can''t stick much data into a 64K block of memory, but back then we had to.
If you wanted more than 64K, you defined it as HUGE.
Now, normally you would have lets say:
char *neardata;
you could set it with malloc();
if you wanted lots of data it was something like
huge char *fardata();
and you created it with farmalloc();
They had defines as NEAR and FAR.
FAR being huge, and NEAR being normal.
Hope that helped.
If not - from borland.
E2022 Array size too large Compiler errorThe declared array is larger than 64K and the ''huge'' keyword was not used.If you need an array of this size, either use the ''huge'' modifier, like this:int huge array[70000L]; /* Allocate 140000 bytes */or dynamically allocate it with farmalloc( ) or farcalloc( ), like this:int huge *array = (int huge *) farmalloc (sizeof (int) * 70000); ?? Allocate 140,000 bytes
btw, like inportb and so on, it''s depricated.
farfree faralloc farmalloc farheapcheck farrealloc inp inpw outp outpw inport inportb outport outportb This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
