M$ Explorer pro Linux (delsi kopie clanku z MSDN)

[Jan Bares]

Creating a UNIX Application Using the Win32 API
Nancy Winnick Cluts
Microsoft Corporation

November 1998

Summary: Details the cross-platform development of MicrosoftR Internet
Explorer 4.0 for UNIX using the Microsoft Win32R 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 Site
Builder Network Workshop Web site at http://www.microsoft.com/workshop/) 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. There wasn't time to start
from scratch and create their own Win32 layer for Unix, so they looked at
vendors that already had such a layer, and tools available. They found two
such vendors: Bristol and Mainsoft. 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 WindowsR, 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 OutlookR 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
(http://www.apogee.com/) 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.


--

Jan Bares
(remove no.spam from my email address)
JPCAD Graphics Engine developer, surf to http://www.antek.cz
PGP ID: 0x6BFE492A