VirtualBox supports multiple monitors…

I’ve been using VirtualBox pretty heavily to partition things out on my systems where some tasks require setups that clash at the OS level.

I generally find multiple monitors to be exceptionally helpful in software development settings. I’ve been running with my Virtual Box VMs on one monitor and using the other monitors for host OS based windows…and this has worked pretty well.

This morning I decided to take a look at the configuration settings for my main VM and to my delight I found that it is possible to configure additional monitors and place them on the desktop. This should streamline things when developing on a VM as it allows me to keep my IDE full screen on one screen while using a second for other activities.

Now if I can only figure out how to make Docker and Virtual Box live together in harmony at home (Docker wants Hyper-V while Virtual Box can’t run under that hypervisor) I’ll be feeling pretty happy.

JSON over Stdin/Stdout for small local components.

I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance.

Unix style text in/text out is limiting as the command/response format lacks structure and the performance (with one process start per request) is potentially unacceptable.

Adding in a command line switch that sets the tool into ‘json in/json out’ mode and keeps the program alive until the pipes drop or an exit command is received should address these issues.

Ideally, the stdin and stdout would transport UTF-8 data containing complete JSON entities…one as a request and one containing the complete response. This can continue until the hosting program sends an EOF or drops the pipes.

I’m wrapping together a very lightweight JSON generator/parser to support this effort and will be following that up with some testing of C++/Java/C# (and perhaps others) sub-process and pipe management coding. If all goes well, I should have a nice little approach for wrapping small pieces of code that need to run in a particular language but must be hosted elsewhere with decent performance and a robust communications format.