0

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. My VxWorks-based GUI application has about 140 K lines.
  2. There are more than 3000 lines containing keywords belonging to Zinc and 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.

Improve this question
10
  • 2
    How large is your application (millions of C++ source lines, or just ten thousand)? How big is your developer team? What kind of application is it? Commented Feb 17, 2016 at 11:51
  • 1
    please edit your question to improve it Commented Feb 17, 2016 at 12:04
  • 2
    port to Windows XP ?!?!?!?!?!?!? Commented Feb 17, 2016 at 12:51
  • 2
    @BasileStarynkevitch You gave him a whole hour to improve it before voting to close?? It's 9pm in Taiwan; maybe he won't check back until tomorrow. Also, he's a new guy; couldn't you give some advice as to how to improve the question? Or at least point him at How to Ask? Commented Feb 17, 2016 at 13:22
  • 1
    Indeed, the 10KLOC figure is a guess from my part. I still believe that the OP should improve again his question by explaining what his application is actually about (and how much is GUI code). Given that it is for VxWorks, I am guessing it is some embedded software. Commented Feb 18, 2016 at 9:42

2 Answers 2

Reset to default
3

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.

Improve this answer
1
  • I think the above comment covers almost every aspect this porting needs to be cared. 1. My company surely hopes to maintain one product line. So, Windows would be the future unique platform, but now right now. Before all old platforms are upgraded to new one, double production line will be maintained for a while. 2. Option #3 seems an appropriate one, but OS Changer is still needed. Although my focus is on GUI portion, the basic porting from VxWorks to Windows will cover some platform initialization codes, system-dependent configuration, ... which is easier if getting help from OS Changer. Commented Feb 19, 2016 at 7:29
1

I would consider porting your code to use Qt because it is a cross-platform GUI framework for C++ (works on Windows, Linux, MacOSX, Android, iOS, ...), and Qt is very powerful. Also, recent Qt versions are C++11 compatible. The current Qt is Qt5.5 (in February 2016), an older version (Qt4.8) was VxWorks compatible.

Alternatively, consider perhaps making your application a web application, perhaps by using FastCGI, or Wt, or HTTP server libraries like libonion.

(without knowing more about your application, we probably cannot help much more)

Improve this answer
5
  • "consider making your application a web application" - this is too presumptious. Whether a Web application is an appropriate replacement for a current Desktop app depends on a lot of factors. Commented Feb 17, 2016 at 12:17
  • It is just a suggestion. We (or at least I) don't understand at all the software to be ported and only are guessing. Also VxWorks does not look like a Desktop OS Commented Feb 17, 2016 at 12:19
  • The point is not whether or not the GUI framework used for porting is cross-platform or not. The point is that the original VxWorks application has lots of calls to GUI library functions which are not compatible with Windows. I was requested to come out a program functioning as the original VxWorks application, so that the customers can use it exactly the same way. Besides, my very point here is the GUI portion. How can I migrate it very efficiently. Commented Feb 18, 2016 at 1:56
  • Hence, you should consider (with your manager) porting your code to Qt. Commented Feb 18, 2016 at 5:53
  • 1
    Porting the program to Qt under VxWorks first before switching to Windows might be an option if the OP wants to support both operating systems in future. If that is not what you meant, you are not answering the actual question, you are just giving the OP a hint how to accomplish option 1 if that is the route he decides to go. Commented Feb 18, 2016 at 12:38

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.