Има ли начин – MFC и Linux?
6 отговора
398 прегледа
Има ли начин – MFC и Linux?
Въпроса ми може да се стори смешен и парадоксален на някой. Има ли начин да се използва MFC под Linux? До сега съм се занимавал само с C++ като ползвам Microsoft Visual Studio 6.0, но искам да драсна нещо за Linux. Мога ли да ползвам библиотеката MFC.
Благодаря на всички.
Благодаря на всички.
в отговор на нeизвecтeн
#3
Re: Има ли начин – MFC и Linux?
За MFC не знам, но WinAPI има... А това означава, че може да си компилираш MFC-то за UNIX. Виж това:
Creating a UNIX Application Using the Win32 API
Nancy Winnick Cluts
Microsoft Corporation
November 1998
Summary: Details the cross-platform development of Microsoft(r) Internet
Explorer 4.0 for UNIX using the Microsoft Win32(r) API. (4 printed
pages)
Introduction
Yes, you read that correctly. I said that you can create a UNIX
application using the Win32 application programming interface (API). And
I have proof. Internet Explorer 4.0 for UNIX was written using the Win32
API. I bet you'd like to know how the team pulled that one off. (I know
I did!) If you are interested in the details, read on.
At TechEd in New Orleans, LA, in June 1998, Digvijay Chauhan,
Development Manager of the Internet Explorer UNIX team, outlined the
cross-platform issues in Internet Explorer 4.0 (for a full list of
cross-platform issues, search for my article "Internet Explorer Runs
Cross-Platform" on the MSDN Online Web Workshop site at
[линк]) as well as how to use
the Win32 API for cross-platform development. This article is based on
the second part of his presentation: Win32 development on Unix. Another
session, titled "Targeting Unix & Windows Platforms with a Single Code
Base: A Case Study" (IOP05) was given at the Professional Developers
Conference in Denver.
Win32 API on UNIX-A Case Study
Imagine that you are on a development team and you are told that you
need to develop a browser using the Win32 API and deliver it on both the
Win32 and Unix (Solaris) platforms. In order to do this, you need to
take into consideration the user interface differences as well as how
you are going to actually code the application. X-Windows has a
different user interface than Windows. With the pace of the software
industry, you do not have the luxury of spending a lot of time and
resources on this project-you must get this browser to market rapidly.
You also must be sure the Unix version has the same rendering fidelity
as the Win32 version. Finally, you must incorporate the Unix look.
That's the challenge that the Internet Explorer UNIX team faced and met.
The targeted time frame was 2-3 months after the Win32 version shipped.
The team consisted of approximately 50 people. There were about 600
Win32 functions that were used by Internet Explorer. Throughout this
project, there were some issues the team had to solve, including
differences in focus, the Component Object Model (COM), the registry,
performance, fonts, UI issues, and portability.
Focus
The biggest area of trouble (read: bugs) had to do with focus. On
X-Windows, the user can configure the workstation for multiple Window
Manager modes and each Window Manager supports multiple modes. This
leads to some interesting differences in the use of focus on Unix versus
Win32. On a Win32-based platform, when the user clicks the mouse once on
a window, that window gains the focus. On X-Windows, you can configure
your system such that the focus follows the mouse. That is, when you
move the mouse to a window, the focus automatically moves to that
window. The workstation can also be set up to support auto raise
focus-when the window gets the focus it is automatically put in the
foreground. X-Windows also supports the single-click to focus scheme
that Win32 supports. The Internet Explorer Unix team had to make sure
the browser they created also supported these different forms of focus.
Modality
In Microsoft Windows(r), it is common for developers to create modal
windows. A modal window is a window that, when it has the focus, does
not let any other window within the application get the focus until the
window is dismissed. For example, if you click the View menu on Internet
Explorer and choose Internet Options, you will bring up a window that
stays in focus until it is dismissed-if you click the Internet Explorer
main window, you will hear a ding and the window will not come into the
foreground. Windows developers create modal windows through the use of
the GetMessage, TranslateMessage, and DispatchMessage functions in a
loop. X-Windows employs a Window Manager that must be told, via hints,
whether a window is modal or not. Unfortunately, this information is
only read once, when the window is shown. The solution to this
difference was to use a new window style hint to tell the Window Manager
the window modality prior to the window being shown.
COM
Internet Explorer relies heavily on the Component Object Model (COM) in
order to function. In fact, any of the window items you see that are
outside of the client area of the screen (for example, the rebar, the
dialog boxes, and so on) are all COM objects. They use COM to
communicate between the browser and the other COM objects. One important
portability problem faced by the team involved using C code to access
COM object methods directly via virtual table (known as a vtable)
structure pointers. The vtable layout is compiler-specific. As a result,
the layout of the pointers is different on Solaris. The solution was to
replace the C code accessing COM objects with C++ code.
Registry
On Windows, the registry is used to store and access information such as
user preferences. Most Windows applications read these values from the
registry in order to persist data from session to session. In Unix, a
user can log on to his workstation and use his home directory from any
machine with all of his settings preserved. Because the registry resides
on only one machine, this is problematic. The team had to figure out how
to share registry information across machines.
Another registry-related issue is synchronization of registry settings
across processes. Okay, that's a complex sentence. In real terms:
Microsoft Internet Explorer and Microsoft Outlook(r) Express share
registry settings. If you change a registry setting in Internet
Explorer, Outlook Express immediately reflects the changes.
The solution was to keep the registry in a location that is shared by
all workstations, leveraging a single home directory. This way,
different processes, regardless of machine, can be in synch.
Performance
The Internet Explorer Unix team created some simple and effective
in-house performance tools to analyze performance bottlenecks and solve
them. One tool wrapped all of the Win32 APIs in order to log the calls
to the APIs as well as determine which thread called the API. This
information was used to identify frequently used APIs and determine
which should be optimized (the ones that were used often) and which were
taking the most time.
Another tool was created to analyze heap space. This was done by mapping
the memory allocation functions (malloc, realloc, and so on) along with
thread identifiers. They were then able to identify resource hogs (image
copy was a big one) and where they could group allocations in order to
maximize performance.
In order to help in the debugging process, they created a program that
modified exception-handling code to determine (via a stack trace) what
caused Internet Explorer to crash. This was particularly helpful in
determining if the testers had found a new bug or one that already
existed, albeit in a new user scenario.
The final tool that was created was a quick and dirty profiler. This
profiler would suspend all threads in a process, sample the program
counter, and map the symbols to get a running count of where the
application was spending most of its time. Here again, the team could go
back and optimize that code.
Fonts
There are a few exceptions to font support using Internet Explorer 4.0
on UNIX. Some fonts are simply not available on Unix. In general,
Windows fonts will be mapped to those available on a particular Unix
server. The Verdana, Arial, and Sans Serif fonts are mapped to the
Helvetica font. The Marlett font is not supported on UNIX at all.
Internet Explorer 4.0 Unix maps fonts to an equal or smaller point size.
In addition, X-based servers can have different configurations and
different font installations. As a result, it was necessary to map fonts
for specific font installations on the server. Internet Explorer 4.x
shipped some prebuilt font caches for standard server configurations.
For nonstandard configurations, a font cache is built the first time the
browser starts; however, this proved to cause a slowdown in startup. As
a result, Internet Explorer 5.0 has changed to an alternate design.
Interface Issues
The Windows interface is different from the look you get when you run
X-Windows-based Motif or common desktop environment (CDE) applications.
The Internet Explorer Unix team had to take into consideration the
different appearance for their version of the browser. Some of the
interface issues that the team had to address were:
A person running Unix is accustomed to using the <CTRL>+<A> and
<CTRL>+<E> key combinations to position the cursor at the beginning or
end of a line respectively.
Tab completion is also an expectation of the X-Windows user. Tab
completion was implemented at the application level by the team.
The middle mouse button is also supported under X-Windows for
copy-and-paste functionality.
Selected text is automatically copied to the Clipboard and available to
be pasted into another application.
Menus stay dropped down after they've been clicked, even after the mouse
moves away from the menu.
Common dialog boxes look different. For example, the CDE File Open
common dialog box and scroll bar widgets are different from their
Windows counterparts. Based on user feedback, the Internet Explorer team
decided to stick with the Windows 3.1 File dialog boxes and the CDE
widgets for scroll bars.
Multiple workspaces are supported by the Window Manager.
Additional system menus are supported under CDE.
CDE integration-including CDE color changes dynamically reflected in the
application-required additional work.
Coding Issues-Portability Problems
When it got down to coding, there were some interesting issues that the
team had to solve, including:
The WCHAR is 4 bytes in most UNIX compilers and 2 bytes in Microsoft
Visual C++(r). As a result, there were many coding bugs found that
assumed the size of a WCHAR was 2 bytes.
Global variables in Win32 dynamic-link libraries (DLLs) are visible
across processes, so it is important that developers are careful that
these globals do not conflict with any variables within the Unix shared
libraries.
Win32 developers have come to rely on Win32 Structured Exception
Handling (SEH) in their applications. Unix does not inherently support
this. With the help of the Internet Explorer team, Mainsoft now includes
fairly complete support for SEH in their Win32 layer.
Visual C++ makes use of keywords for alignment, such as unaligned. The
Unix team had to write macros to do alignment.
Compilers for Unix do not support nameless nested structures.
Summary
All of this was a lot of work and the Internet Explorer Unix team
learned a lot from it. In the future, they plan to use a common code
base between their Win32 and Unix versions so that a change in one will
automatically be reflected in the other. They are planning to use the
Apoge compiler ([url][линк][url]) for this common code base. They
also plan to incorporate the feedback they get on interface issues. In
the meantime, you now know that you, too, can develop your Unix
application on Win32. The Internet Explorer team did it and so can you.
--------------------------------------------------------------------------------
Send feedback to MSDN.Look here for MSDN Online resources.
Creating a UNIX Application Using the Win32 API
Nancy Winnick Cluts
Microsoft Corporation
November 1998
Summary: Details the cross-platform development of Microsoft(r) Internet
Explorer 4.0 for UNIX using the Microsoft Win32(r) API. (4 printed
pages)
Introduction
Yes, you read that correctly. I said that you can create a UNIX
application using the Win32 application programming interface (API). And
I have proof. Internet Explorer 4.0 for UNIX was written using the Win32
API. I bet you'd like to know how the team pulled that one off. (I know
I did!) If you are interested in the details, read on.
At TechEd in New Orleans, LA, in June 1998, Digvijay Chauhan,
Development Manager of the Internet Explorer UNIX team, outlined the
cross-platform issues in Internet Explorer 4.0 (for a full list of
cross-platform issues, search for my article "Internet Explorer Runs
Cross-Platform" on the MSDN Online Web Workshop site at
[линк]) as well as how to use
the Win32 API for cross-platform development. This article is based on
the second part of his presentation: Win32 development on Unix. Another
session, titled "Targeting Unix & Windows Platforms with a Single Code
Base: A Case Study" (IOP05) was given at the Professional Developers
Conference in Denver.
Win32 API on UNIX-A Case Study
Imagine that you are on a development team and you are told that you
need to develop a browser using the Win32 API and deliver it on both the
Win32 and Unix (Solaris) platforms. In order to do this, you need to
take into consideration the user interface differences as well as how
you are going to actually code the application. X-Windows has a
different user interface than Windows. With the pace of the software
industry, you do not have the luxury of spending a lot of time and
resources on this project-you must get this browser to market rapidly.
You also must be sure the Unix version has the same rendering fidelity
as the Win32 version. Finally, you must incorporate the Unix look.
That's the challenge that the Internet Explorer UNIX team faced and met.
The targeted time frame was 2-3 months after the Win32 version shipped.
The team consisted of approximately 50 people. There were about 600
Win32 functions that were used by Internet Explorer. Throughout this
project, there were some issues the team had to solve, including
differences in focus, the Component Object Model (COM), the registry,
performance, fonts, UI issues, and portability.
Focus
The biggest area of trouble (read: bugs) had to do with focus. On
X-Windows, the user can configure the workstation for multiple Window
Manager modes and each Window Manager supports multiple modes. This
leads to some interesting differences in the use of focus on Unix versus
Win32. On a Win32-based platform, when the user clicks the mouse once on
a window, that window gains the focus. On X-Windows, you can configure
your system such that the focus follows the mouse. That is, when you
move the mouse to a window, the focus automatically moves to that
window. The workstation can also be set up to support auto raise
focus-when the window gets the focus it is automatically put in the
foreground. X-Windows also supports the single-click to focus scheme
that Win32 supports. The Internet Explorer Unix team had to make sure
the browser they created also supported these different forms of focus.
Modality
In Microsoft Windows(r), it is common for developers to create modal
windows. A modal window is a window that, when it has the focus, does
not let any other window within the application get the focus until the
window is dismissed. For example, if you click the View menu on Internet
Explorer and choose Internet Options, you will bring up a window that
stays in focus until it is dismissed-if you click the Internet Explorer
main window, you will hear a ding and the window will not come into the
foreground. Windows developers create modal windows through the use of
the GetMessage, TranslateMessage, and DispatchMessage functions in a
loop. X-Windows employs a Window Manager that must be told, via hints,
whether a window is modal or not. Unfortunately, this information is
only read once, when the window is shown. The solution to this
difference was to use a new window style hint to tell the Window Manager
the window modality prior to the window being shown.
COM
Internet Explorer relies heavily on the Component Object Model (COM) in
order to function. In fact, any of the window items you see that are
outside of the client area of the screen (for example, the rebar, the
dialog boxes, and so on) are all COM objects. They use COM to
communicate between the browser and the other COM objects. One important
portability problem faced by the team involved using C code to access
COM object methods directly via virtual table (known as a vtable)
structure pointers. The vtable layout is compiler-specific. As a result,
the layout of the pointers is different on Solaris. The solution was to
replace the C code accessing COM objects with C++ code.
Registry
On Windows, the registry is used to store and access information such as
user preferences. Most Windows applications read these values from the
registry in order to persist data from session to session. In Unix, a
user can log on to his workstation and use his home directory from any
machine with all of his settings preserved. Because the registry resides
on only one machine, this is problematic. The team had to figure out how
to share registry information across machines.
Another registry-related issue is synchronization of registry settings
across processes. Okay, that's a complex sentence. In real terms:
Microsoft Internet Explorer and Microsoft Outlook(r) Express share
registry settings. If you change a registry setting in Internet
Explorer, Outlook Express immediately reflects the changes.
The solution was to keep the registry in a location that is shared by
all workstations, leveraging a single home directory. This way,
different processes, regardless of machine, can be in synch.
Performance
The Internet Explorer Unix team created some simple and effective
in-house performance tools to analyze performance bottlenecks and solve
them. One tool wrapped all of the Win32 APIs in order to log the calls
to the APIs as well as determine which thread called the API. This
information was used to identify frequently used APIs and determine
which should be optimized (the ones that were used often) and which were
taking the most time.
Another tool was created to analyze heap space. This was done by mapping
the memory allocation functions (malloc, realloc, and so on) along with
thread identifiers. They were then able to identify resource hogs (image
copy was a big one) and where they could group allocations in order to
maximize performance.
In order to help in the debugging process, they created a program that
modified exception-handling code to determine (via a stack trace) what
caused Internet Explorer to crash. This was particularly helpful in
determining if the testers had found a new bug or one that already
existed, albeit in a new user scenario.
The final tool that was created was a quick and dirty profiler. This
profiler would suspend all threads in a process, sample the program
counter, and map the symbols to get a running count of where the
application was spending most of its time. Here again, the team could go
back and optimize that code.
Fonts
There are a few exceptions to font support using Internet Explorer 4.0
on UNIX. Some fonts are simply not available on Unix. In general,
Windows fonts will be mapped to those available on a particular Unix
server. The Verdana, Arial, and Sans Serif fonts are mapped to the
Helvetica font. The Marlett font is not supported on UNIX at all.
Internet Explorer 4.0 Unix maps fonts to an equal or smaller point size.
In addition, X-based servers can have different configurations and
different font installations. As a result, it was necessary to map fonts
for specific font installations on the server. Internet Explorer 4.x
shipped some prebuilt font caches for standard server configurations.
For nonstandard configurations, a font cache is built the first time the
browser starts; however, this proved to cause a slowdown in startup. As
a result, Internet Explorer 5.0 has changed to an alternate design.
Interface Issues
The Windows interface is different from the look you get when you run
X-Windows-based Motif or common desktop environment (CDE) applications.
The Internet Explorer Unix team had to take into consideration the
different appearance for their version of the browser. Some of the
interface issues that the team had to address were:
A person running Unix is accustomed to using the <CTRL>+<A> and
<CTRL>+<E> key combinations to position the cursor at the beginning or
end of a line respectively.
Tab completion is also an expectation of the X-Windows user. Tab
completion was implemented at the application level by the team.
The middle mouse button is also supported under X-Windows for
copy-and-paste functionality.
Selected text is automatically copied to the Clipboard and available to
be pasted into another application.
Menus stay dropped down after they've been clicked, even after the mouse
moves away from the menu.
Common dialog boxes look different. For example, the CDE File Open
common dialog box and scroll bar widgets are different from their
Windows counterparts. Based on user feedback, the Internet Explorer team
decided to stick with the Windows 3.1 File dialog boxes and the CDE
widgets for scroll bars.
Multiple workspaces are supported by the Window Manager.
Additional system menus are supported under CDE.
CDE integration-including CDE color changes dynamically reflected in the
application-required additional work.
Coding Issues-Portability Problems
When it got down to coding, there were some interesting issues that the
team had to solve, including:
The WCHAR is 4 bytes in most UNIX compilers and 2 bytes in Microsoft
Visual C++(r). As a result, there were many coding bugs found that
assumed the size of a WCHAR was 2 bytes.
Global variables in Win32 dynamic-link libraries (DLLs) are visible
across processes, so it is important that developers are careful that
these globals do not conflict with any variables within the Unix shared
libraries.
Win32 developers have come to rely on Win32 Structured Exception
Handling (SEH) in their applications. Unix does not inherently support
this. With the help of the Internet Explorer team, Mainsoft now includes
fairly complete support for SEH in their Win32 layer.
Visual C++ makes use of keywords for alignment, such as unaligned. The
Unix team had to write macros to do alignment.
Compilers for Unix do not support nameless nested structures.
Summary
All of this was a lot of work and the Internet Explorer Unix team
learned a lot from it. In the future, they plan to use a common code
base between their Win32 and Unix versions so that a change in one will
automatically be reflected in the other. They are planning to use the
Apoge compiler ([url][линк][url]) for this common code base. They
also plan to incorporate the feedback they get on interface issues. In
the meantime, you now know that you, too, can develop your Unix
application on Win32. The Internet Explorer team did it and so can you.
--------------------------------------------------------------------------------
Send feedback to MSDN.Look here for MSDN Online resources.
в отговор на нeизвecтeн
#4
Re: Има начин – QT!
Za linux polzvai QT
spored mene e dosta po syvremenna ot MFC-to,
bezplatna e ima si dosta info/samples/doc i tn.
[линк]
spored mene e dosta po syvremenna ot MFC-to,
bezplatna e ima si dosta info/samples/doc i tn.
[линк]
Re: Има начин – QT!
wsushnost ne e bezplatna a _free_ - po tochno svobodna.
Sus GPL license e ako wuznamerjawash da pishesh i ti sus GPL - t.e. trjabwa da si pusnesh sorsovete sled tova (ne sum siguren dali shte mozhe da prodavash applicationa) [линк]
i ima QT license - kojto ti dawat ako ne ikash da puskash sorsovete - no struva veche pari.
Wuw firmata kojato rabotja bih iskal da izpolzwame QT wmesto MFC - no neznam dali shte im se haresat tezi licensionni prava...
Um tzaruwa, Um robuwa, Um belia delfin
Sus GPL license e ako wuznamerjawash da pishesh i ti sus GPL - t.e. trjabwa da si pusnesh sorsovete sled tova (ne sum siguren dali shte mozhe da prodavash applicationa) [линк]
i ima QT license - kojto ti dawat ako ne ikash da puskash sorsovete - no struva veche pari.
Wuw firmata kojato rabotja bih iskal da izpolzwame QT wmesto MFC - no neznam dali shte im se haresat tezi licensionni prava...
Um tzaruwa, Um robuwa, Um belia delfin
в отговор на нeизвecтeн
#6
Re: Има ли начин – MFC и Linux?
ako njakoga ti potrjabwa tool/portable biblioteka za GUI izpolzwai tova
wuw google napishi
[линк] "GUI"
[линк]
izglezhda za dosta dulgo vreme tova vodi to dosta populjarnata stranitza
[линк]
razgledaj QT, GTK (i raznowidnostite mu), wxWindows, Fox ili FLTK
Um tzaruwa, Um robuwa, Um belia delfin
wuw google napishi
[линк] "GUI"
[линк]
izglezhda za dosta dulgo vreme tova vodi to dosta populjarnata stranitza
[линк]
razgledaj QT, GTK (i raznowidnostite mu), wxWindows, Fox ili FLTK
Um tzaruwa, Um robuwa, Um belia delfin
в отговор на нeизвecтeн
#7
Re: Има ли начин – MFC и Linux?
Mislq che tuka e otgowora na twoq wypros :
[линк] - ako tiq bratoci ne lyzhat, mozhesh da si portnesh
wichkite prilozheniq napisani na MFC ili sys Stingray ili raznite mu tam COM/DCOM i drugi Microsoft tehnologii samo s edin "click". Ama mozhe i da lyzhat. Az lichno ot dosta wreme se kaniq da go probwam towa chudo, ama wse ne namiram wreme.
[линк] - ako tiq bratoci ne lyzhat, mozhesh da si portnesh
wichkite prilozheniq napisani na MFC ili sys Stingray ili raznite mu tam COM/DCOM i drugi Microsoft tehnologii samo s edin "click". Ama mozhe i da lyzhat. Az lichno ot dosta wreme se kaniq da go probwam towa chudo, ama wse ne namiram wreme.