I thought about Rob Pike’s piece on the value of physical prints. He gives three examples: Photos from the Scott Antarctic expedition, photos from his family and, as contrast, tapes containing early development records of the Unix operating system. He talks about the need for curation of digital information regarding software, hardware and formats. I miss a prior step: Realizing that something of value can be found in the haystack of bits; the Identification of valuable data.
Once the penguin poo was cleaned off the films from the Antarctic, it was clear what they were. You could already get a good idea about their content by holding them up against the light. Even simpler for the shoe box of family photos, no penguin poo (I presume). The content was immediately identifiable. In case of the DECtapes, I imagine they were marked and contained relatively few different things.
Now imagine someone inheriting your hard drives. Assume they are readable - hardware, file system, file formats and all. Said someone now has huge piles of data created by you mingled with data you just consumed. There are audio files mixed with videos mixed with spread sheets mixed with pictures mixed with other stuff, probably badly (“not”) separated into own and foreign work and in crude folder hierarchies. Hopefully the lucky heir is willing to put in the work required to separate the good hay from the worthless hay.
Prints have an additional function: If it is important enough to print, odds are, it has some worth. It eases the identification part of the process.
From a perspective of someone who has exclusively used Unix/Linux programming environments in his academic and private life, Visual Basic 6 really is an oddball - one that I have to deal with in work life, though. Since it lives on Windows, it has to deal with the weird separation of “subsystems”, which firmly divides console and graphical applications at link time. Your program can either be a console application, forcing a console to open even when you start it via the explorer, or it can be a graphical application, allowing no output to stdout.
And since VB was only meant for graphical applications, the programming environment does not expect you to link the program to the console subsystem. Consequently, VB6 also does not provide constructs to write to stdout.
You can still make it do so, it’s just a bit more painful:
Public Const STD_OUTPUT_HANDLE = -11& Public Declare Function stdout Lib "kernel32" Alias "GetStdHandle" _ (Optional ByVal Handletype As Long = STD_OUTPUT_HANDLE) As Long Public Declare Function WriteFile Lib "kernel32" _ (ByVal hFile As Long, ByVal lpBuffer As Any, ByVal nNumberOfBytesToWrite As Long, _ Optional lpNumberOfBytesWritten As Long, Optional ByVal lpOverlapped As Long = 0&) As Long ... Dim hStdOut As Long Dim sWriteBuffer As String hStdOut = stdout() sWriteBuffer = "Hello World" WriteFile hStdOut, sWriteBuffer, Len(sWriteBuffer)
After compiling the .exe, you have to manually relink it to the console subsystem:
link /edit /subsystem:console application.exe
No wonder the whole “using one program’s output as another program’s input” thing isn’t more popular on Windows…
I moved all my Git repositories from GitHub to my own server. Three months ago, there was a scare that a GitHub’s new Terms of service would essentially invalidate copyleft licenses on projects. This interpretation of the new ToS turned out to be (most likely) false, but it got me thinking: Why rely unnecessarily on a third party, when I don’t need to? I have already had one bad experience with flickr. Thus, I self-host now.