(win32 / OWRT Embedded Linux / Linux (gcc))
This 2d spatial points search will efficiently search an arbitrarily populated 2d point space and find the closest 'n' points that lie within a radius 'r' away from a search point(px,py). It primarily uses quad trees for subdivision and heavily relies on pointers, and other non-copy intensive strategies to minimize memory footprint.
I have strongly-mixed feelings about this endeavour. On the one had it was an interesting forray into a bunch of rarely-used mechanics and is a great example of quality/completeness, on the other hand it is the final nail in the coffin of why I will never accept to do an unpaid interview project again. Developers be warned, despite clocking in at over 1200 lines and many weeks of work/research into new areas, the submission was never even downloaded/viewed, by employer.
Still, as a pedagogical perspective, I hope at least anyone interested in space-partitioning, or a generic implementaion of quad trees will find this useful.
In its current form though, as a DLL project, the application suffers from direct usability.
For a future release I do plan to have a directly Linux/GCC buildable version. For a period during development it actually was done as such but eventually migrated itself into the current Win DLL form, to interface with said company's caller application.
Added (Aug 29, 2023)
>Download
This is a minimalistic Windows service designed to allow you to designate one or more independent batch files(and by extension, exes) to be run on system start-up as the "System" user. The service process (BatchWrapperService.exe) simply calls CreateProcess() starting "cmd.exe" for every line in the input file. Each input file line denotes an absolute path to a batch file which in turn can reference an executable to load. The choice to run intermediate batch files instead of directly calling executables stemmed from the need to invoke arbitrary java applications. Batch files allows for defining arbitrary applications/argument groups on start-up, whereas supporting arguments sent directly to CreateProcess() would have required some parsing work.
Once launched, the batch file (and by extension, exe) is completely independent from the wrapper service, and if the service is stopped there is no effect on it. The program which is launched from the service must have some means to be controlled already.
At any rate, as it stands the service runs more than well enough to simply get things going once the OS boots.
The binary was compiled on WinXP, Visual Studio 2005, .NET 2.0
For Win7 and later it should register and run out of the box.
For WinXP you may need the 2005 C++ runtimes and .NET 2.0 installer.
To Install:
1.) Create a directory "C:\BatchWrapperService1\"
2.) Put "BatchWrapperService.exe" into it.
3.) Create a txt file there called "BatchWrapperService_Inputs.txt" where each line is a complete path to a batch file you want to run.
4.) Open a terminal (cmd.exe) in that directory and run "BatchWrapperService.exe -Install" you should see a blurb and at the end it will say "The transacted install has completed."
5.) Open "services.msc" and you should now see an entry for "BatchWrapperService1", right click it and go to properties and you can set its startup type to "Automatic" to load when windows starts.
After the service has started you'll notice some runlogs, one is for the main service ending in "_RunLog.txt" This is overwritten every time and shows the parsed lines of the input file, start time, and working (current)directory. Runlogs with numbers are listed for each cmd that was started, the number designating its PID.
Future work could include sending a WM_QUIT message to each of the launched programs upon stopping the service. However, since they are batches run in cmd.exe this is not so straightforward. Cmd blocks on the batch to complete, but killing it doesn't kill programs started in the batch. To alleviate this a new input file format could be implemented which also accepts direct exes, which could then be sent a WM_QUIT message directly. The hard-coded paths should be removed as well. Unfortunately I was unaware of how to deal with how windows services were started (from %WinDir%\System32), so I hard-coded everything to
"C:\BatchWrapperService1\".
A call to find the actual service exe's location and then reset the path to this could trivially be added.
Updated (Aug 19, 2020) (added solution upgraded to vs2013 + CPP.Net 4.0)
>Download
This was a recent submission for a pre-interview wherein a periodic, polling client was to be created specifically to interact with the Phillips HUE platform. The platform itself is an interesting, multi-device, read-write control point thats surprisingly well documented. Its most obviously used to control lights, but as in the docs, lists several device types and endpoint methods.
The main codebase leverages libcurl which is compiled into the project to give it simple http functionality, and supplies the application with error support via curls extensive error types.
Upon startup the user can set the hostname:port where the HUE API is currently live, and they may also set how often it is polled.
After getting a list of lights the app will then sit, continuing to poll, and begin to note changes it sees to any of the lights in the system. If there is any sort of error encountered in the response cycle the program will terminate.
Lastly, the responses are all performed in JSON format so the application needed a standardized way to interpret this.
Due to this I created the included Json parsing library (MyJson.h/MyJson.cpp) which, in the future, will probably be expanded out to allow for ease of usability. This, I felt, supplied a niche wherein it provided for the most basic, complete, and yet non-exotic task of being able to parse and writeout correct, arbitrary JSON in C++. At the same time the structure isn't needlessly cutting edge, and will compile in older environments not meticulously kept up with C++ 9000. Due to its basic, yet still fully functional structure I think its worth separating it out eventually, perhaps with documentation even.
A (node-based) HUE Simulator exists and can be read about here.
https://www.npmjs.com/package/hue-simulator
After node is running on your system simply do the following:
$ npm install -g hue-simulator
$ hue-simulator --port=8080 &
Added (Jan 29, 2021)
>Download
A VERY preliminal start on a project for OpenWRT, specifically v15 Chaos Calmer, implementing a general-purpose relay. This can be extended, by user implementation of the MagicModify() method for all sorts of uses, specifically obfuscation.
Generally considered, its behavior is identical to other utilities such as socat, although it gives the user access to the byte stream.
Not documented, but there should be enough commentes for anyone determined enough.
This, along with a whole family of relays coded in java, will eventually be released/extended at some point.
Added (Aug 19, 2020)
>Download