A collection of Windows functions predefined for you via Win32::API.
Hence the 'pr', for 'Pure Ruby'.

gem install windows-pr

require 'windows/path'

class Foo
  include Windows::Path

  if PathIsRoot.call("C:\\") > 0
    ...
  end

  # or

  if PathIsRoot("C:\\")
    ...
  end
end

Each of the various files included as part of this package provide a series
of constants corresponding to the equivalent Windows API function and
related numeric constants.  For example, if you require 'windows/path',
you now have PathIsRoot, PathIsUNC, etc, available to you as Win32::API
objects in the form of constants.

A wrapper has been provided for each method in order to avoid the
Win32::API#call method. So, instead of PathIsRoot.call(path) you can
invoke it as PathIsRoot(path). If the original function is lower case
then the wrapper method is lower case as well.  For example, instead of
doing 'Memcpy.call(dest, src, size)' you can do 'memcpy(dest, src, size)'.

Remember boys and girls, if you write 'PathIsRoot', you're referring to
the constant. If you write 'PathIsRoot()', you're calling the wrapper
method.

Boolean methods automatically perform a check for success or failure. So,
instead of having to do something like 'if PathIsRoot(path) > 0' you can
just do 'if PathIsRoot(path)'. However, I do not add this nicety for the
MSVCRT functions that return int's because some functions have multiple
return values which you may want to inspect. So, rather than making you
guess, I have simply declared that you must inspect return values manually
for any MSVCRT module.

Source files contain related functions, by topic. For example, the
clipboard.rb file contains clipboard related functions, such as
CloseClipboard(), as well as constants such as CF_TEXT, CF_BITMAP, etc.

I decided that the $KCODE handling was a bad idea, so most of the $KCODE
handling has been removed. The only methods that change their behavior
based on $KCODE are the multi_to_wide and wide_to_multi helper methods
in the Windows::Unicode module. If $KCODE is set to UTF8, then the code
point used is CP_UTF8. Otherwise, CP_ACP is used.

The modules all come with explicit ANSI and Wide (Unicode) functions,
when available from MS Windows. By default, a function without an explicit
'A' at the end of the function name uses the ANSI version. It is up to you
to use the wide ('W') functions explicitly if you wish.

Not all functions are defined on all platforms. For example, the
 AttachConsole() function is only defined on Windows XP and later. If you
eed to conditionally test for its existence, simply use the 'defined?'
method:

if defined? AttachConsole
  # Do something
else
  # Do something else
end

While I've made some effort to test these functions, there are simply too
many for me to effectively test them all. We're ultimately talking about
hundreds, if not thousands, of functions, and I don't know what all of them
actually do. That being said, I will add tests where and when I can.

If you find that I've declared the function prototype wrong for a given
function, please let me know ASAP and I'll fix it.  An example program
demonstrating the problem would be helpful, too.  Or, if you'd just like
to contribute some test cases, that's fine as well.

I became tired of redefining Windows functions over and over whenever I
wanted to use the Win32API library. I thought it would be very handy to
have them predefined for me in a library with convenient wrapper methods
to boot.

While it's true that Moonwolf has a library on the RAA that includes many
of these functions defined already, there are a few issues with it. First,
it puts *every* function and constant in one or two files. That's a waste
of memory, hard to organize & maintain, and impossible to test. Second,
some of his function declarations are wrong. Third, some of the functions
I needed for my own projects are missing. Fourth, there's no gem. Lastly,
I haven't seen an update in over 6 years, which leads me to believe it is
no longer maintained.

I have only defined a small subset of the overall Windows API. It would
take me years to define them *all*. I defined the ones I needed first,
plus some that I thought would be useful to others. I will continue to
add functions in my spare time, or (especially) by request.

None that I'm aware of. Please report any bugs on the project page at:

https://github.com/djberg96/windows-pr

The only real bugs you should find are either bad prototype declarations
or bad constant values.  Sometimes I forget to wrap functions properly
that may not be defined on older Windows platforms.  But, please report
any of these issues on the project page should you stumble into them.

In some cases the MSDN docs are wrong, and we have to learn it the hard
way. If you should happen to find a documentation bug on their site,
please contact them and let them know. They're generally good about fixing
them.

In other cases library functions are not exported by the dll. For example,
my version of shlwapi.dll does not export the PathIsHTMLFile() function,
despite being well past the minimum version for that DLL. There is nothing
you or I can do about it short of rebuilding the DLL file from scratch
and/or reporting the issue to Microsoft.

I only support the Windows NT family of Windows, and then only Windows
2000 and later.

I plan on converting this library to use FFI instead of win32-api. There
is already an ffi branch with some of that work done.

Artistic 2.0

This package is provided "as is" and without any express or
implied warranties, including, without limitation, the implied
warranties of merchantability and fitness for a particular purpose.

(C) 2006-2014, Daniel J. Berger
(C) 2016-2020, Hiroshi Hatake
All Rights Reserved

Daniel Berger
Park Heesob
Hiroshi Hatake