AstroDMx Capture is being developed as a single code-base for multiple operating systems. It is a huge project that now exceeds 50 KLOCs (a KLOC is a thousand lines of Source Code) and this does not include the many thousands of lines of internal documentation within the code.
This might all seem to some observers like the never-ending story. In a sense, it is, because AstroDMx Capture will continue to be maintained and increased in capability. The bulk of the compiling is done on a Fedora Linux machine using cross-compilers where required and only compiling in a native environment for MacOS or Windows when necessary.
The incorporation of the Windows operating system into AstroDMx Capture is what has taken quite a lot of time. This is because Windows is not a POSIX compliant operating system, and so does things frequently, in a fundamentally different way to the POSIX compliant UNIX and UNIX-like operating systems such as Linux, MacOS and FreeBSD.
This is all quite ironic. To explain what I mean, I will give a short excerpt from a book that Nicola and I are writing, and will be publishing when we get time.
'In the early 1980’s there were three branches of UNIX development: Firstly, UNIX system III from the Bell laboratories UNIX Support Group. Secondly, Berkeley Software Distribution (BSD®) from the University of California at Berkeley. The third branch of UNIX development was Microsoft’s XENIX®, a version of UNIX that ran on the X86 family of processors’ and licensed from AT&T Corporation. In fact, in the early 80s, XENIX had the largest installation base of any UNIX system. UNIX fragmentation produced compatibility problems between UNIX versions which gave rise to the formulation of the POSIX® standard (Portable Operating System Interface for UNIX), which was an attempt to standardise the system-call interface in order to maintain compatibility between operating systems.
Even Microsoft with Windows NT had a go at being POSIX compliant. This because they wanted to win an Air Force contract. The Federal Information Processing Standard required that some types of government software purchases had to be POSIX compliant. Microsoft incorporated the Microsoft POSIX subsystem into the first versions of Windows NT. However, the Windows NT POSIX subsystem did not incorporate a POSIX shell or any UNIX commands. However, the system was sufficiently POSIX compliant to win the contract. They continued with incorporating SUA; a Subsystem for UNIX-based Applications. This was finally removed in Windows 8.1. It is important to understand that being UNIX does not depend on, for example, having a certain kernel; it depends on meeting a number of criteria, mainly POSIX compliance, to conform to the Single UNIX Specification. If Microsoft had gone all of the way in making Windows POSIX compliant, Windows too could have been classified as UNIX. This was obviously not what Microsoft wanted,' which is a huge shame!
The irony goes even further because having removed their Subsystem for Unix-base applications (SUA) in Windows 8, Microsoft have now implemented in Windows 10, WSL (Windows subsystem for Linux) that allows Linux applications to run in a sort of Wine in reverse compatibility layer. WSL2 on the other hand, actually incorporates a Linux kernel in a Virtual environment, yes a Linux kernel sitting alongside the Windows kernel!, so Linux applications can run on a Linux kernel without the requirement for a Wine-like compatibility layer. However, this seems to me to be half-hearted and certain ports and functions cannot be passed through to the WSL2. Microsoft have done this because their Azure cloud systems essentially run on Linux machines and they want a command-line Linux to be available to developers from within Windows.
Nicola has virtually completed the implementation of AstroDMx Capture in Windows, but it has been nowhere as straightforward as working within the constraints and confines of regular Windows frameworks, whilst protecting against the future effects of systems that have bee deprecated by Microsoft, such a Direct Show.
Testing AstroDMx Capture for Windows with the SV305Pro camera
The SV305Pro is the most recent member of the SVBONY family of cameras.
From left to right are the SV105, SV205, SV305 and the SV305Pro.
Note the blanking plug that we have inserted into the guiding port of the SV305Pro to prevent accidental attempts to insert the camera data cable into the guiding port.
The SV305Pro camera was attached to the camera port of a research-grade trinocular microscope.
AstroDMx Capture for Windows was used to capture data on Nematode micro-worms from the SV305Pro camera on the microscope.
Screenshot of AstroDMx Capture for Windows streaming data from the SV305Pro
A SER file was captured of the nematodes
Snapshot of some nematodes captured by AstroDMx Capture for Windows
The camera worked almost flawlessly with AstroDMx Capture for Windows and good results were obtained. There are however, still some issues that may be SDK related, and further testing will be required to resolve them.
Testing AstroDMx Capture for 64 bit Rasbian on a Raspberry Pi 4B with the SV305Pro camera
