I use ODBC to access databases in my C/C++ coding and in my PowerBASIC coding. Whenever I'm having difficulties with anything, I call SQLGetDiagRec(), which returns error info. I can provide for you a bit of code to try it out. Let me know.

Thanks very much Richard and Jochen. It dawned on me yesterday afternoon while taking a walk (which is how I solve most of my programming problems) that I needed libc - not GNU GCC sources. Just now before checking in here I managed to download libc in tarball format. Now I need to see if I have an app to extract tarballs. I much appreciate your help! Thanks very much!

I think I'm on the right track Richard. I downloaded Subversion for Windows from SourceForge, but it doesn't look like I have to use it. By replacing svn:// with http:// I can browse to sources as just ftp folders. I've gotten this far... https://gcc.gnu.org/svn/gcc/trunk/ https://gcc.gnu.org/svn/gcc/trunk/libgcc/ Perhaps I just need to spend some time searching for pow. Haven't found it yet.

How does one view/obtain the GCC C sources? I don’t know how to use git. I just downloaded a Windows version yesterday (haven’t installed it yet), and am studying an ebook on it. Or should I use GitHub? I don’t know anything about these things. Is there an easier way to do it? Is there an ftp site where you can just download it from without having to learn/use some complicated source code management system? I’ve nearly completed writing my own version of only what I need from the C Standard Library, and all I need from the C++ Standard Library is a String Class, and I’ve used my own for many, many years which works fine. The only thing I need yet is a full implementation of pow, and possibly exp if pow needs that, and I don’t know how to do it myself. That’s why I need to study and learn from the GCC C sources. I’m linking without the Standard Libraries so as to avoid the bloat, and using Windows. But if I’d have asked here first how to implement pow, within 1 minute of posting that question I’d have been told to look at the GCC sources, which I don’t know how to do. That’s why I’m asking for instruction here first on that. Once I’ve figured out how to get at the GCC sources, then I can tackle my pow issue. I'm not the only one baffled by this... Apparently, I downloaded the wrong program ( git ), and am studying the wrong book. Apparently I've got to learn how to use svn before I can even attempt this? This is ridiculous, in my opinion. I guess what I'm looking for is a list of all the hoops I've got to jump through to get what I want. Something like this... 1) Download and install Subversion (and hope there is a Windows version of it); 2) Buy a book that teaches how to use Subversion; 3) Figure out how to use Subversion to navigate to GCC sources; 4) Find pow or exp and figure out how it works; Is the above what I should do, or is there some other route?

Thanks Jochen! I'm making progress. Put in a brutal day yesterday and got that asm code working for me in both asm and VC9 C++. Lost some hide but finally got it to work. Here's some of my by now dried blood... Uggh. Don't know how to do links here. :( What you said above about there not being much change in the fpu unit between the various processors makes sense and I'm heartened by it. It also says that in the fpu tutorials at masm32.com I have the asm source for the code that is doing what I need. Perhaps I could get myself a 64 bit assembler and reassemble it. But at this point I'm making progress and today hopefully will be able to incorporeate my newly working float routine into my string class code. If I can't then I'll tackle the GCC sources. I appreciate your pointing me in that direction and providing the links and info.

[QUOTE] I don't see the relation between 64 bit and basic floating point operations (regardless if implemented by emulation, FPU, or vector instructions) when using a C compiler. [/QUOTE] Well, perhaps I'm laboring under false knowledge. I have a 32 bit masm created FPU lib, i.e., fpulib.lib, which has within it the function I need, e.g., ... FpuFLtoA(...) ...which returns through an out parameter my floating point number converted to a Z string. I can't link that 32 bit library into 64 bit code can I? I just assummed not, because of the fact 32 bit dlls can't be directly used by 64 bit binaries. And thanks again for the information on those various functions deep in the internals of printf. I hadn't looked into that end of it deep enough to determine where they were implemented, but what you told me closes that possibility, apparently. Where I'm at now is if I'm to use your links to download the GCC sources I apparently have to install and learn to use git. Years ago I worked with Linux some but never became terribly proficient in that world. Never could find anything comparable to the Windows Api for writing GUI apps. About the closest thing I could find that I could marginally tolerate was GTK. I liked XLib but it wasn't suitable for creating GUI apps (no controls (widgets). But unless you tell me I can link 32 bit libraries into 64 bit executables, or somehow I can come up with a 64 bit FPU lib (if I need it), I see studying the GCC sources as my only hope?

Thanks for the thoughtful responses Jochen and Richard. Much appreciated. Here's where I'm at. Just got Raymond Filiatreault's fpulib working for me from www.masm32.com. Its part of the masm32 install. Really nice. So next my intent is to write a C prototype for the function I need and either link against the *.obj or even the lib. However, I'm some disappointed at this point. I was really hoping to solve my 64 bit bloat issues with all this, but Raymond Filiatreault's fpu lib is 32 bit. By the way, it was easy to get Matt Pietrek's LibCTiny.lib working in x64; just a tweak here and there. But while it would be satisfying to get all my stuff working in 32 bit, I really want 64 bit. Would either of you guys know of a 64 bit fpu lib available anywhere? As you mentioned Jochen, maybe I ought to check out the GCC sources. As an aside, looking at Microsoft's printf.c and _output.c code gets into some pretty ugly stuff. There's an array of function pointers like so... _cfltcvt ...and some other undocumented functions involved in the floating point conversions. But I'm tickled at the size reductions I've achieved. A simple "Hello, World!" with my string class is around 70 k with VC 9 from VS 2008, /MT build. With the C++ Std. Lib's string class we're at around 92 k. With my String Class and LibCTiny plus a half dozen additions to it I had to make, I'm only at like 6 K!!!!!

Nope. Doesn't work. Unless someone can tell me different, here's the way I see it. Even if I find a Windows specific function that will take as an input parameter a floating point number and output into a character buffer an asci or wide character rendering, I won't be able to use it against the /NODEFAULTLIB linker switch, because it'll just be a wrapper that calls one of the functions in the C Runtime. And it'll give me linker errors. That's what happened with StringCchPrintf(). So at this point, unless someone can tell me different, I see my only choices as these two... 1) Give up on any window/console/file output using floating point numbers without the C Runtime; 2) Write my own floating point package involving the fpu. I guess I'll try option #2 above. I see at the masm32 site there is an fpu package with assembler source available. However, I hadn't mentioned, I'm really doing 64 bit and need that. So I've got my work cut out for me. The reason I'm doing this is because I hate the bloat of modern software. Can't take it anymore. I like C++ OK but I won't use any C++ Std. Lib. code. I write all my own library code, string class, dynamic multidimensional arrays, whatever I need, etc. So now I guess I need to come up with my own floating point code. Please save me somebody! Tell me I'm wrong!

Shoot! I think I got it! Tried the 1st on my list above, i.e., StringCchPrintf() and it did it. Its in StrSafe.lib. I hope to God that doesn't use the C Runtime or I'm back to square one! I'll let you all know! Fred

Been working on Matt Pietrek's code from an old Microsoft Systems Journal article he wrote about eliminating the C Runtime (LIBC or LIBCMT) from my C++ executables, i.e., using the linker /NODEFAULTLIB switch. Your own Mike_V wrote a tutorial on that here too... http://www.codeproject.com/Articles/15156/Tiny-C-Runtime-Library Everything's working GREAT for me with it except for one point which really has me scratching my head. I can't figure out how to convert a floating point number to its string representation without using one of the printf family functions in the C Runtime. Of course, Win32 'covers' or has its own versions of some of these functions, e.g., wvsprintf in user32.lib has a format specifier parameter, but its not complete; it has everything but %f, which we need to convert a floating point number to a string buffer (try it and you'll see - it doesn't work). And I obviously can't use the C Runtime functions if I'm trying to eliminate them! Does anyone know of a Win32 function which can be used to convert a floating point number into a provided character string buffer??? On MSDN I found a whole bunch of odd named functions I'm totally unfamiliar with... StringCchLength StringCchPrintf_l StringCchPrintf_lEx StringCchPrintf StringCchPrintfEx StringCchVPrintf_l StringCchVPrintf_lEx StringCchVPrintf StringCchVPrintfEx ...and was wondering if anyone knows if any of these or perhaps some other exists which would solve my problem?

PowerBASIC is the other half of my coding arsenal - the rest of it being C and C++. Given a choice, I'll use PowerBASIC before I'll use C or C++, and I'm equally skilled in either coding environment. Where I can't readily use PowerBASIC is in non desktop Windows environments, for example Windows embedded or CE. For Windows desktop development I'll always go with PowerBASIC. Speed wise, its equivalent to C. If you're into asm, it has its own inline assembler. If you're into using the Windows Api as I am, you have the same access to it as you have with C or C++. The place where it kills C or C++ is in string handling. There is nothing like have a string type built right into the compiler. For this reason it produces much smaller executables than C++ which must essentially compile some string library or other into the executable. The only way you can produce a smaller executable is to use C with no string class, i.e., use the low level strcpy type string buffer primitives. Also, it has easy support for COM; both high level and low level. All in all, its dynamite.

I've studied up on the issue enough to have convinced myself that any further effort to use any system capabilities to determine the count of bytes previously written to an IStream would be fruitless. While Microsoft's documentation does push the analogy that IStreams are pretty much like files, the fact is that the analogy only goes so far. It appears that some file capabilities don't exist for IStreams in compound storage, and I'd guess at this point marking the end of written bytes is one of them. It follows from this that there is nothing akin to a SetEndOfFile(). It occurs to me that these missing capabilities could be coded into an app that uses compound document files, for example creating a seperate IStream to store the actual length of data written into other IStreams.

Thanks for the feedback Electron. Been mulling over the problem and it occurred to me I may not be able to use the STGM_SIMPLE flag in the STGM parameter, but may need to use the full transacted mode (with ::Commit() to get record counts to work. I'll read up on it this evening, and maybe try it again tomorrow. It would be neat to get this to work. If structured storage has this limitation, its going to be useless to me. I'm not ready to give up just yet though. :)

This is a basic COM Compound Document or Structured Storage question. I created an IStream within an IStorage and wrote four of these (each four bytes) to that IStream…

typedef struct tagINDEX
{
DWORD dwPlotRecord; // 4
}INDEX; //==
// 4

The Storage was created like so…

wchar_t szFile[]=L"C:\\Code\\VStudio\\VC++6\\Projects\\COM\\CompStor\\CmpStr07\\Release\\Data.dat";
IStorage* pStorage=NULL;
DWORD grfMode;
HRESULT hr;

grfMode=STGM_SIMPLE | STGM_CREATE | STGM_READWRITE | STGM_SHARE_EXCLUSIVE ;
hr=StgCreateDocfile(szFile,grfMode,0,&pStorage);

I can read those four records out of my IStream using IStream::Read() but have been unable to determine the correct byte count of the four records (each four bytes) I wrote in with IStream::Write(). Since each INDEX record is four bytes and I wrote four such records ‘in’, then I’d hope to obtain an…

IStream::Stat(STATSTG*, STATFLAG_NONAME)

…return where the STATSTG.cbSize.LowPart would equal 16. This is not what is returned to me, but rather the number 4096, which looks suspiciously to me like a sector size, which I’m further assumming was the initial memory/file allocation for the IStream. It does not appear to me that Streams have an analogous function to the Windows Base Services GetFileSize() Api. Does anyone know anything about this? How do you get the number of bytes actually written to a Stream as opposed to the total allocation for the Stream? I'm just teaching myself COM Compound Document Storage Interfaces, and was doing rather well until I hit this problem! I'll provide some additional information. Here is what got written into a Simple IStream...

Now Try To Put Data In Structured Storage!
szFile = C:\Code\VStudio\VC++6\Projects\COM\CompStor\CmpStr07\Release\Data.dat
StgCreateDocFile() Succeeded!
pStorage->CreateStream(Index) Succeeded!
Will Now Try To Write Index Records To Structured Storage
dwNumPlots = 4

i idx.dwPlotRecord pcbWritten

1 1 4
2 3 4
3 4 4
4 5 4

After having written those 16 bytes and Releasing() both pStream and pStorage, then re-opening both, that's where I ran into the difficulty. Here is a short program with output afterward showing that even S_OK is returned by reading pa

Here is a link to very extensive work & code concerning this, that is, dumping VTables and VPtrs... http://www.jose.it-berater.org/smfforum/index.php?board=362.0