---
created_at: '2015-09-30T14:56:08.000Z'
title: Creating a Unix Application Using the Win32 API (1998)
url: http://www.linux.cz/pipermail/linux/1999-September/051669.html
author: thwarted
points: 42
story_text: 
comment_text: 
num_comments: 39
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1443624968
_tags:
- story
- author_thwarted
- story_10304411
objectID: '10304411'

---
[Source](http://www.linux.cz/pipermail/linux/1999-September/051669.html "Permalink to  M$ Explorer pro Linux (delsi kopie clanku z MSDN)
   ")

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

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

**Jan Bares** [jan.bares na antek.cz.no.spam ][1]  
_Steda Z 1 17:01:25 CEST 1999_

* Pedchoz pspvek: [M$ Explorer pro Linux ][2]
* Nsledujc pspvek: [M$ Explorer pro Linux ][3]
* **Zprvy tdn podle:** [[ data ]][4] [[ vlkna ]][5] [[ subjektu ]][6] [[ autora ]][7]
* * *
    
    
    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
    
    
    

* * *
* Pedchoz pspvek: [M$ Explorer pro Linux ][2]
* Nsledujc pspvek: [M$ Explorer pro Linux ][3]
* **Zprvy tdn podle:** [[ data ]][4] [[ vlkna ]][5] [[ subjektu ]][6] [[ autora ]][7]
* * *

[Dal informace o konferenci Linux][8]  

[1]: mailto:linux%40linux.cz?Subject=Re%3A%20M%24%20Explorer%20pro%20Linux%20%28delsi%20kopie%20clanku%20z%20MSDN%29&In-Reply-To=%3C7qjbir%242bck%241%40ns.felk.cvut.cz%3E "M$ Explorer pro Linux (delsi kopie clanku z MSDN)"
[2]: http://www.linux.cz/051705.html
[3]: http://www.linux.cz/051699.html
[4]: http://www.linux.cz/date.html#51669
[5]: http://www.linux.cz/thread.html#51669
[6]: http://www.linux.cz/subject.html#51669
[7]: http://www.linux.cz/author.html#51669
[8]: http://www.linux.cz/mailman/listinfo/linux

