PROGRAMMING STATUS:
  At least a little PROGRESS finally made after having had LOTS of recent setbacks!
  Lately I've been trying to get my backup program working after some significant changes that I'd made in it.  For one of these changes in particular--adding in code that also checks for and copies any alternate data streams--I'd found major problems with this on my XP computer (with my Windows 8 computer having an untrustworthy hard disk and therefore not currently being usable as my primary computer for doing my programming on).  The problem is that in Windows XP, there is no 'FindXXXStreamW' (XXX=First/Next) functions in Windows API.  So in order for it to access streams on the XP--being that they do in fact exist there but are just not easily accessible as such--I've had only a couple ways of potentially getting around this problem.
  So as my first chosen method for doing so, I'd decided to go the route of accessing the "Native" Windows operating system directly (which is done via the 'NTDLL.DLL' library).  So I've had to set up a call--first of all--to either NtCreateFile or NtOpenFile in order to receive the necessary HANDLE to the source files in order to then grab the Stream information, which is ultimately made available to accessing via these functions.
  Never having been a Windows Drivers-related programmer before this point in time, at first I made the mistake of accessing these functions via using LoadLibrary on the 'ntoskrnl.exe' file--which is access to the actual Kernel-mode-running Kernel itself--my not having known this to begin with, which was producing a bizarre affect of causing the program to usually return back to several functions down lower on the stack, skipping several functions that had been awaiting return!  Once I figured out my mistake--to instead use LoadLibrary on 'ntdll.dll' as the User-Mode entry point to these same functions, then I finally started making a bit better progress...at least without having bizarre behavior occurring in the program.
  But then I was finding that it was continually reporting a misalignment error to me (0x80000002, STATUS_DATATYPE_MISALIGNMENT), no matter WHAT I would try.  In fact, I even went so far as to finally try setting the alignment for every point-type involved to every single byte for each between the original and 511 bytes beyond the original for each pointer, with it containing 3 different pointers involved in the call to NtOpenFile, with it thereby testing this function call using 512*512*512= 134,217,728 different settings, this being the quickest and easiest way of testing it even though I knew that lots of these addresses, especially the "odd"-starting addresses, would of course be invalid.  But it was still the fastest and simplest test to program into it at the time, having it report on any such combinations that no longer created this alignment error.  But there ended up being absolute NONE!  Every single pointer-alignment scenario produced this same exact error, with no exceptions, thereby proving to me finally that it hasn't really at all been an issue concerning the alignments of any of my supplied pointers/buffers involved while calling NtOpenFIle after all.
  So next, I found online articles about simple programs that have been proven successful at accessing the Native operating system, particularly involving the use of the function NtCreateFile from USER mode from within an Windows API type of program (and NOT for the sake of a Driver).  In fact, it even provided an example of the C code that was proven to work, which creates a new file and writes a "Hello World" into it using the NtCreateFile functions along with others as well.  But it had to use a Windows DDK (Driver Development Kit) in order to compile it.  So I had to download and install one of these DDK's first--my trying to get one that hopefully would work okay for my XP at this point even though Microsoft no longer supplies them for it--which I've actually succeeded at doing although things aren't perfectly setup to work together properly whatsoever.
  While attempting to build this small downloaded project using Visual Studio programs such as NMAKE, which is new for me being that I've been using 'Cygwin' for years now instead, I nevertheless finally was able to get it to work good enough to succeed just moments ago.  Part of what helped me greatly in doing so is that I'd already had downloaded and installed--years ago although going unused so far--several versions of both 'Visual Studio' as well as 'Microsoft SDK' and even--although I haven't needed them yet--the 'Debugging Tools for Windows' that contains the Windbg program (that I may have used once a long time ago for something).
  So what has happened, therefore, is that I've been EXTREMELY lucky to succeed at getting this 'Hello World' program to actually eventually compile and then run successfully today, working as expected, even with my having had to add in all types of things into both my 'INCLUDE' and 'LIB' environmental variables from all over the place just in order to satisfy unfound files, with my having NO idea while doing so whether the various involved versions of everything were at all matching up with each other.  I used version 7.0A for getting things from my SDK environment that were found there, version 10.0 for getting things from my Visual Studio environment, and the DDK/WDK version that I'd just downloaded and installed and was using for this today apparently was version 1830 associated with Windows XP SP1, I believe, although I also later downloaded but haven't yet installed the DDK/WDK for Windows XP SP3 which I think was labeled for Windows Server 2003 if my memory isn't failing me, which probably would have been the better one to have used.  Anyway, even with all of these versions likely being misaligned with each other and even with my ignoring a 'Warning' from the linker about some of the '.rdata' sections having different attributes (LNK4078, C0000040), it still ended up producing the file upon its very first run and with the proper "Hello World" text having been written within it!  So now I've FINALLY made a wee bit of progress in resolving this latest stumbling block and can--from this--go back into my backup program now and gradually infuse things from this Hello World program where it is successfully calling the 'NtCreateFile' function into my call to 'NtOpenFile', which simply MUST result in eventually fixing the problem.  If it doesn't help at first, I can always switch from calling the easier 'NtOpenFile' function to instead calling 'NtCreateFile' function, being that the result will be exactly the same, with my now having a copy of a proven call to this function that actually works!
  And then once I therefore finish getting both this NtOpenFile/NtCreateFile thing resolved and working along with all related calls that I also make to the Native Windows API, then I'll finally be able to start debugging my accessing of the Alternate Data Stream information, which shouldn't be anywhere near as troublesome to deal with.  Part of the problem with using these Native Windows API calls is that they contain references to things that I've had no prior knowledge about dealing with such as mainly IRQL's and APC's, which I'm still not very clear on other than my yesterday seemingly having learned that I probably won't need to really worry about these, I don't believe, in my simple situation such as it is being that I'm doing nothing with any actual Windows Drivers or Kernel Mode coding.
  So this has all been pretty both discouraging and difficult for me lately over these last two weeks to make much progress here with this, although as a backup--if I would have completely failed by using the Native Windows API functions--then at least I had a 2nd option of trying to use the Windows API function 'BackupRead', which also should be able to grab the Alternate Data Stream information, although I have still never used it yet and simply preferred trying to use what had SOUNDED like an easier and more-clearly documented method for getting to the Stream information for files on the XP.  But at least now I--as a result--have not only gotten past all of these troubling blockades to my progress so far, but I've also ended up with one DDK installed and another slightly more recent DDK that I can install as well whenever I might desire to.  Plus, I can now also even write Windows Drivers, if I ever either need to or want to at some point in the future, although obviously it will still involve a lot of learning for me to successfully do so.
  So soon, I hope, I can finally get my backup program fully debugged and working well and THEN I can FINALLY use it to try and save my Windows 8 machine before it's completely DEAD (which it frequently in the past several years has teased at becoming) followed then by my FINALLY getting back to my Spreadsheet program and trying to finish that up so that I can start using it on my Android smartphone, being that I'd burned out my prior one, which is why I'd started writing the spreadsheet program in the first place with hopes to replace existing programs with one that will be tailored to me and hopefully will run with a lot less processing involved so that I won't burn out any further of my smartphones as I intend to eventually continue to use mine IN PLACE OF for mostly all things done on computers.  The End.  (For the moment that is...LOL).
