Return to Answer

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, make the cost estimation for coming to a decision between option no 1 and 2. Consider also a mixed strategy - for example buying Zinc for Windows, and implement something like a "WindML emulation layer" on Qt.

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.

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 fewest 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, 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.

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 a suitable instruments 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), 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, and compare that also to the price of buying a Windows version of Zinc and/or WindML. 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, make the cost estimation for coming to a decision between option no 1 and 2.

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, make the cost estimation for coming to a decision between option no 1 and 2. Consider also a mixed strategy - for example buying Zinc for Windows, and implement something like a "WindML emulation layer" on Qt.

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 at least 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, 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.

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 a suitable instruments 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), 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, and compare that also to the price of buying a Windows version of Zinc and/or WindML (is there a latter available?) 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.

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 fewest 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, 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.

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 a suitable instruments 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), 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, and compare that also to the price of buying a Windows version of Zinc and/or WindML. 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, make the cost estimation for coming to a decision between option no 1 and 2.