The Place and Future of QuickWin

[dboggs]

As a newbie, I hope that someone can shed light on a QuickWin cloud.

We are beginning to develop some apps, mostly updating a pile of old ones, for access to limited windows features such as more memory, child windows, basic dialog boxes etc. We are now on CVF but want to get more current. To satisfy management concerns about long-term "stability", serious questions about being tied to a particular operating system, whether we should be developing full windows apps vs. limited (QuickWin) more portable apps, etc, I'm seeking answers to some basic questions.

When I look at Intel's website promotional info on 11.1 Fortran for Windows package, there is no mention of Console vs. QuickWin vs. full Windows development, even though I'm sure these are all still supported. What should I conclude from this?

Is it the intent of Intel to continue support for all of these?

Is there a parallel situation in the packages for Linux and Mac? i.e. in those packages,are there offerings for windows-like features or is it just standard Fortran? Is there anything comparable to quickWin?

I try to make a case for using Fortran as opposed to Matlab, C++, etc. based on the excellent long-term standardization of Fortran. But if we use anything besides Console applications, is this argument blown full of holes? If we need to use some basic Windows features, yet be faced with migratingapps to Linux or Mac (or who knows what) in the future, are we better of in IVF developing Windows apps or QuickWin apps?

[Steven_L_Intel1]

Continue support of QuickWin? Yes. Port to other platforms? Probably not. Console applications are fundamental and not going away. I like to say that QuickWin is good for giving a traditional Fortran console application a "Windows look and feel", but it has its limitations, as users have found, so it's not for everyone.

There are third-party libraries that provide easy graphics and menus on multiple platforms. GINO is one I know of. None of these have the Fortran I/O integration QuickWin has.

[Paul_Curtis]

Wonderful post, excellent question. I can't speak for Intel, but my company is heavily invested in IVF F90 apps which are extensively, probably inextricably at this point, invested in the full Win32 API, and provide full GUI features as well as imbedded Win32 features such as multithreaded operations, Winsock communications, etc. Almost none of this would be possible with Quickwin; you need to write your own procs and fully process message loops without an intervening abstraction layer in order to realize acceptable commercial performance and features.

The bet (well, mine anyway) is that MS will continue to support the Win32 API in future evolutions of Windows, which will continue to be seen as a cost-effective and secure platform. In my market sector (application-specific SCADA systems) there is absolutely no presence of Apple or Linux or anything else, and the issue of cross-platform performance is of no importance; your mileage may vary.

[garylscott1]

GINO and Winteracter do in fact have sufficient capability to produce commercial quality applications. They do not support every Windows API bell and whistle, however, they make it possible to build a commercial quality application in 1/3 the time of programming to the Windows API. I've done both. Once you know the GINO API for example, you can write simple but usable Windows applications about as fast as a console application. Of course the more you dress it up, the more time you spend on the UI.

[Nick2]

I think your best bet is to separate your app (at the top level) into a "generic" part and a "platform specific" part.

Once you do that, perhaps the "platform specific" part targets a standard console. This is the most portable of all options, and also allows you to specifically test only the Fortran part of your app.

I'm assuming your primary dev platform is Windows. So the next step is to write a second"platform specific" port to a .dll library. This perhaps involves changing "program main" to "subroutine main(...)". Now you can easily load your .dll into C++ codeand from there you can take it wherever you want. You can use Windows API (which I know from experience withMicrosoft,the Windows API is more feature complete than even their flagship WPF), a bunch of libraries, UI/graphics and otherwise, interface to C++/CLI which takes you to WPF/C#/VB.NET, you name it. If you have engineers and UI designers, this split approach works out great.

So the question is, what do you want to do with it. If you don't have sophisticated UI requirements, IVF does provide the bread and butter UI components and Windows API modules out of the box. If you want to start simple and grow it, IVF can do that too.

In terms of portability, my main app runs on anything that has a Fortran compiler, and I'm not kidding lol. The Windows version has a really nice UI, and the Linux folks are quite happy with a console version. Helps them with batch jobs too.

[dboggs]

Thanks everyone for these answers. I need to look into GINO. I'm still wondering about the IVF packages for Linux and Mac: can I create window-like features using these? Obviously not with the Windows API. 1. Is there something similar to Windows API on these platforms that is utilized by IVF? 2. Is an independent library used to do it, similar to GINO or QuickWin? 3. If it is possible, is it any easier to use than Windows API? Finally, I still find it surprising the Intel offers no information on these questions in their promotional material on their Fortran/Mac or Fortran/Linux compilers, or even on the IVF/Windows compiler!

[Nick2]

On Windowsthey call it "Intel Visual Fortran" and it hasVisual Studio IDE.

On Mac/Linux they call it "Intel Fortran" and it has the command line compiler that you can usewith makefiles. Last time I checked there is no Visual Studio or any IDE included.

So if you're looking for a multi-platform GUI library, it has to come from outside of IVF. ForTran is more meant for writing engineering formulas than flashy GUIs.