@Araq: Haven't been able to check, but thanks for uploading this anyway.
Question: What is going to replace oldwinapi/windows and why did you phase out the windows module? What about the winlean module? How do all these modules relate to each other?
The winlean module is what the standard library requires to work and is the base for a new API wrapper that Varriount is working on (I think). The new API wrapper will consist of more than a single monstrosity module covering everything and so will be nicer to work with and it will be more up to date.
Also the old windows module doesn't adhere to our style guidelines and has lots of cruft in it.
The new wrapper is going to be mainly generated from documentation available on MSDN, with some additions where automated parsing/generation can't be done or doesn't make sense.
The current plan I'm working with is to use this to extract the Windows API documentation, run the generated files through c2nim, then edit the output Nim files until they compile successfully. After that, additions can be added to make working with the wrapped procedures more natural, such as procedure variants using enum types for flag-like parameters, automatic exception raising, etc. I haven't completely planned it yet, as I need to get a sense of what is feasible first.
Edit: To elaborate further, here's a brief overview of how I'd like the wrapper to be. Functions and structures will be placed in files named the same as the header file/dll they reside in (for example, CreateFile would be in FileApi.nim (or possibly kernel32.nim, I haven't decided). All identifiers (with the exception of parameter identifiers) would be changed to Nim style guidelines.
@Araq (three posts back) mentions that winlean will be replaced by a new wrapper.
The <http://nim-lang.org/docs/lib.html> page already sends the winlean link nowhere.
Should I just wait for its replacement? What might that be named?
Can I just insert a declaration of the GetModuleFileName that I need from the windows API? What would the nim code be?