Dialog rc To source code utility

Started by James C. Fuller, January 11, 2017, 05:09:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

James C. Fuller

Patrice,
  Can you give me a list of the functions you need? I'm not sure I have the ability to add them but I can give it a go.

James

Patrice Terrier

#16
For example: timer, sqr, rnd, sin, cos, abs, mod, just to give a few (must work with: int, float, double).

I have attached a simple LaserBeam OpenGL visual plugin, to compile as a DLL, for you to try.
(VS 2015 community project)

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

James C. Fuller

Patrice,
  rnd,mod and timer are not c++ intrinsics that I'm aware of??
I am working on the trig functions now and they appear to be working fine.

James


Patrice Terrier

 rnd,mod and timer are not c++ intrinsics that I'm aware of??

timer:
time(NULL);

rnd:
rand()

RANDOMIZE TIMER:
srand((DWORD) time(NULL));

mod:
% // for int
fmodf // for float
fmod // for double

Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Frederick J. Harris

I'm going nuts with issues now and can't get to it, but the math.h functions could be easily added to TCLib's capabilities.  The issue with that is as follows.  In my original work on TCLib my intention was to recode everything myself from scratch that I needed from the C Runtime.  The only place I got stuck was on Math.h, specifically pow(), i.e., raising a floating point number to a floating point exponent.  That is one partuicular function I absolutely needed.  I didn't know how to do it.  I downloaded the C Runtime source from GCC, but I simply ran out of time trying to figure it out.

Next step or movement in the drama was my discovery that Microsoft's Windows operating systems automatically loads msvcrt.dll into every GUI process it starts.  If you don't believe me simply run Mark Russinovitch's utility that shows all the dlls loaded into a process.  What you'll find is that every GUI process - even the very simplest with just a blank Window, has msvcrt.dll loaded into the process.  Not true for console processes but absolutely true for GUI processes that make calls into user32.lib and gdi32.lib.

Having absorbed that reality it dawned on me that if that's the case - and it is, why should I be wearing myself out writing code replacements for functions that are loaded into my process anyway and which I'm powerless to eliminate?

The creators of mingw felt likewise and that's where they get their C Runtime functionality, i.e., from msvcrt.dll.  For their part Microsoft isn't thrilled about that outcome, because its their position that a Windows installation isn't a 'Delivery Channel' for the C Runtime.  They would prefer folks use the 'versioned' instances of the C Runtime provided with Visual Studio, statically link against them, or provide them to users as redistributables. 

But all the C Runtime functions are there and msvcrt.dll is part of the operating system, i.e., it'll always be there.  Its a protected operating system file.    I've stated elsewhere that Bob Zale up through version 9 of the Windows compiler included a copy of msvcrt.dll in his /bin subdirectory of his installation, and since noting that, I've always been curious what use he made of it internally. 

In any case, my present versions of TCLib get most of their stdio functionality through function pointers to the functions in msvcrt.dll rather than through code I've written.  That is how pow() works too.  The trig and other functions could easily be implemented likewise.  I didn't because I don't do much surveying work anymore.  I used to years ago, and may again at some point, but I didn't need it right now.  Actually, its so easy to add it I could do it in a few minutes.

James C. Fuller

Fred,
  Thanks for the insight. I am in the process of adding the math functions. Piece of cake. :)
I know you are busy with personal stuff  and preparing  for retirement. We can tackle more and interesting stuff for TCLib after you retire.

James


Frederick J. Harris

Thanks for taking a look at it Jim!  Its just a matter of looking at what I did in the crt... functions with InitStdio() and InitMath() and using those architectures/templates for the other Math.h functions.  Sounds like you've got it. :)

Mike Lobanovsky

Frederick,

Your observation is absolutely correct and logical. There's no need to re-invent the wheel since msvcrt.dll has always been, and will continue to be, a dedicated user space system library on every Windows machine regardless of OS version since at least Windows'95 (might be even earlier than that; too lazy to check out myself now) onwards. Most of monkey work about classic C functionality is usually initiated by those devs who are obsessed with their code portability to other platforms. msvcrt.dll supports all common math and trig that one may ever need in one's general purpose applications. Versioned runtimes of later Visual Studios are normally only needed if you tend to get irritated too much by the VS obtrusive warnings about your using "deprecated" vocabulary, or if your customers/contractors appear to be overly picky in their design docs and technical specs.

Moreover, msvcrt.dll is guaranteed to remain backward and forward compatible throughout all Windows versions.

On the other hand, there is one more system-wide C language runtime called crtdll.dll. This one is meant to interact with the kernel space processes and might not be ABI compatible between different Windows versions, depending on the particular design solutions in a version's kernel. Even though it may seem to offer functionality similar to that of msvcrt.dll, it is usually a bad (unsafe) idea to link a user app directly against it unless your creation is a native application (a.k.a. driver) that would usually rely heavily on a particular kernel implementation and/or computer hardware.

In most cases, msvcrt.dll serves as a mere proxy between an ordinary user space application and the crtdll.dll-to-kernel32.dll bundle, which proxy ensures everlasting and transparent API/ABI compatibility and interoperability of any user space code with the underlying kernel space processes.

That said, and provided your code uses at least one explicit or transparent call to either user32 or gdi32 library API, you may safely assume that msvcrt.dll will get mapped into your process memory automatically as well regardless. So, why not use it for your own purposes to the fullest if your app isn't intended as a hermaphrodite Jack of all trades on two masters' errand? :)
Mike
(3.6GHz Intel Core i5 w/ 16GB RAM, 2 x GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

Frederick J. Harris

Thanks for the input Mike.  I never knew much about NTDll.  I've seen it show up in debuggers, but didn't know much about it.