It's particularly useless for anything else, really. Not to mention it's in a completely un-portable format. One can only hope this was generated automatically.
"Un-portable" in that it wraps the win32 API rather than implementing the API. But it's actually a pretty handy format if you wanted to generate wrappers for other languages -- replace a couple base types/functions and have it emit code to wrap the Win32 API for any other language.
And yeah, it's pretty obviously automatically generated.
No you cant. It is NodeJS module referring node-ffi - module allows you to call dynamic libarary functions w/o making your own binary module. So it may be used with NodeJS under Windows. For example you may access COM ports directly from JS. Or you may send messages to other Windows to manipulate them.
Possibly with https://github.com/tjfontaine/node-libclang. I'm actually working on a node module that will automatically parse header files using libclang and make native dynamic libraries available with no configuration required on the end of the developer. It will eventually be part of https://github.com/olalonde/better-require if you're interested.
An didn't know about this, looks great. Would you be interested in helping me write an add-on for better-require? Anyways, I'll try it out and see how it works out.
The actual code generator I haven't published because it was kind of a pile of crap. I created bindings to libclang as well here but haven't finished rewriting a more generalized code generator from it https://github.com/Benvie/node-clang/blob/master/bindings.js
What appears to be missing is the automatic mapping of the A (ansi) and W (wide) suffixed function names to conventional unsuffixed function names. In C, this is done using macros. If UNICODE is not defined, the macro MessageBoxEx would expand to MessageBoxExA. With UNICODE, the macro expands to MessageBoxExW. Similarly, TEXT is used to wrap strings to ensure they're unprefixed or prefixed with an L respectively. You could do this by hand, it's just a bit more tedious to write.
One would wish these distinctions could be forgotten with calling the Win32api from JS. However, that is a pipe dream and could have an impact on performance.
You can forget the distinctions without impacting performance if your JavaScript engine uses UTF-16, because that's the native encoding of Windows NT 5.0+. You'll still get overhead when working with binary data, Typed Array or not.
This is fascinating, but I just can't discern a practical purpose.
The novelty of the "I just converted this huge piece of software written in c or machine code into JS" type of post usually extends only to the title. The link itself generally serves only to evoke a profound "WTF" (and in this case took upwards of 40 seconds to load.)
Although I appreciate the undertaking of compiling prodigious libraries, drivers, etc. into JS, I don't see practical value in the product of said undertaking.
The fact that this practice has proliferated throughout HN recently is odd. This kind of thing is certainly remarkable, but it doesn't do anything.
You're 100% right but you're missing something here. Something like this takes skill and builds skill and when you've finished you just want to show it off. And it really is impressive! Sure, it has no practical application itself but I'm sure that some piece of this or some technique used in porting it to JS will have some practical value somewhere. Sometimes the practical is born from the impractical.
I guess what I'm saying is why does it need to do anything or be practical? Cool stuff is just cool sometimes.
Windows script host (cscript) allows you to execute js files in addition to vbscript (vbs). This is particularly useful in extending the functionality of batch files. This can be useful in a lot of circumstances build process, installation etc.
Windows script host (cscript) allows you to execute js files in addition to vbscript (vbs). This is particularly useful in extending the functionality of batch files. This can be useful in a lot of circumstances build process, installation etc.
sarvesh, you were hellbanned more than 3 years ago. His post:
Windows script host (cscript) allows you to execute js files in addition to vbscript (vbs). This is particularly useful in extending the functionality of batch files. This can be useful in a lot of circumstances build process, installation etc.
39 comments
[ 2.7 ms ] story [ 98.0 ms ] threadThis is the beginnings of a windows registry library https://github.com/Benvie/node-winreg
This is an example of creating a windowless event loop in order to create a low level keyboard/mouse hook https://github.com/Benvie/node-Windows/blob/master/input.js
Thank you for publishing this.
And yeah, it's pretty obviously automatically generated.
http://www.microsoft.com/resources/documentation/windows/xp/...
Things like accessing namespace folders, creating shortcuts, etc are easier through this WHost interface than the raw API.
You can for instance get processes informations, start a wave sound, and many more.
Scroll down to the middle to see API calls.
One use-case is using CoffeeScript or JavaScript to write tools that would benefit from these calls (could be system tools, or not).
The novelty of the "I just converted this huge piece of software written in c or machine code into JS" type of post usually extends only to the title. The link itself generally serves only to evoke a profound "WTF" (and in this case took upwards of 40 seconds to load.)
Although I appreciate the undertaking of compiling prodigious libraries, drivers, etc. into JS, I don't see practical value in the product of said undertaking.
The fact that this practice has proliferated throughout HN recently is odd. This kind of thing is certainly remarkable, but it doesn't do anything.
I guess what I'm saying is why does it need to do anything or be practical? Cool stuff is just cool sometimes.
Windows script host (cscript) allows you to execute js files in addition to vbscript (vbs). This is particularly useful in extending the functionality of batch files. This can be useful in a lot of circumstances build process, installation etc.
That said, WinRT doesn't expose Win32 API. Well done. That takes dedication, skill, and lack of sanity.
> Edit WinRT API link: http://msdn.microsoft.com/en-us/library/windows/apps/br21137...