DistantMacOS_Thoughts.md 2.2 KB
We are now beginning planning for the work of refactoring or adopting the refactor of Distant VDI to include the MacOS platform This means we need to think about native development in the Mac operating system environment look at analogs for some of the more complicated or paradigmatic solutions we've enclosed our work into and find some wisdom in terms of how best to implement them for Mac some of the technologies that we need to think about in particular are Our Serializer/Deserializer and whether the protobuf for mac has any changes that we need to be aware of For one, we need to look at whether or not we can build with protobuf 3.14 from Mac, or if that changes too many things in which we case we can just use a similar process and just add the 3.13 lib/binary/includes directly ZeroMQ and SPDLOG both seem to have widespread support on Mac I still need to confirm that the Citrix Workspace App for MacOS is a thing and that the Virtual Driver has the same API as what we're already accustomed to I would expect little change, if any at all When it comes to some of the syntax restrictions we incurred when reimplementing code to have it compile on Windows, we likely went through the most restrictive changes that we need to worry about I would expect that it wouldn't be quite so difficult to do it on Mac, as they are argued as more faithfully fulfilling the standards of POSIX compliance tnux but that is, of course, up for debate Posix Spawn is another thing we have to think about, but it seems to be also implemented on Mac, as is expected due to POSIX compliance we might need to weed out some differences there, and make amendments to the process_host accordingly Again, when it comes to C library based utility functions that we're using in the common tools for the project, it's likely that we'll be able to use the POSIX-compliant code as is (currently under the preprocessor condition of being "Linux") The window appears to be a different story, however, as it's likely that the code needs to be written to make use of the cocoa library, or something has to be written in Swift in any case, we need to have something which is wrapped in C++ code, and ObjectiveC++ might be a better fit thatn Swift for that reason exit