My company has an old GUI application on VxWorks. Now, I was requested to port this application to Windows XP over new H/W platform. The original application calls WindML & Zinc (Tornado's GUI libraries). For successfully porting this application, I can figure out these approaches:rewrite GUI functions using VC++ on Windows: This could very time-consuming for the original designer didn't expect this porting. Even he did, the effort is still to heavy.develop WindML/Zinc-compatible libraries in Windows using VC++: That is, replace the original VxWorks GUI libraries into compatible Windows GUI libraries. This could be more systematic, but the effort is still very heavy.Configure WindML/Zinc into Windows version: that is, the VxWorks's IDE, Tornado can be configured to build image for Windows. This approach is most efficient. But unfortunately, for some reason, it was not allowed in my company.Use OS Changer of MapuSoft: MapuSoft claims that their product, OS Changer, can serve this job. But the issue is that OS Changer is still very strange to me. I don't have confidence for it. I don't know how much it can serve it.Further information about my application:My VxWorks-based GUI application has about 140 K lines.There are more than 3000 lines containing keywords belonging to Zincand more than 2000 lines containing keywords belonging to WindML.Is there any other approach for porting GUi among different OS platforms? I know the porting project contains not only GUI portion, but other new H/W dependent portion. But now, I point is only on GUI portion.
Port GUI program from VxWorks to Windows
visual c++
First thing you should get clear is if the application has to be maintained under both operating systems after the port. If that is the case, you should prefer a solution with as few duplicate code as possible, which means a solution where you either reuse the original libs or use compatible libs. Your option number 4 might be appropriate for this. But I assume that further maintenance is planned to be on Windows only, otherwise you would not have suggested the oher alternatives. If I am right, option no 4 is probably not the way to go.Next thing you need is a better cost estimation for the remaining alternatives. The number of lines using keywords of framework XY is a start, but still not the best indicator for the effort. When changing the framework, there will be bigger portions of the code to be reimplemented than those 5000 lines you mentioned, you need to identify how much code is directly dependent from these parts. So if it is possible to isolate the parts / modules directly related to the GUI, count the lines of that modules - these are the parts to be rewritten, and for ports, LOC is often a suitable instrument for a rough cost estimation.Now try to make an estimation how long it would take to rewrite these parts (maybe using some framework like Qt - option 1), compare that to an estimation of how long it will take to create Zinc & WindML compatible libs for Windows in a suitable quality by yourself (option 2), and compare that also to the price of buying a Windows version of Zinc and/or WindML (option 3). Even if your company has decided against option 3 (yet), your superiors might become open for a discussion again when they see your cost estimation.Note that for option 3, Windows versions of Zinc and/or WindML must be available, and you need some trust into the vendors that they guarantee long-term maintenance. Otherwise, forget option 3. The cost estimation will still be useful for deciding between options 1 and 2. Consider also a mixed strategy - for example buying Zinc for Windows, and implement something like a WindML emulation layer on Qt.