HACKING.txt

// -*- Mode: Text; tab-width: 4; -*-

Table of Contents
-----------------

  * History
  * Checking Halyard Out of Git
  * Downloading Halyard
  * Building Win32 Halyard
  * Rake
  * Building Mac OS X Halyard
  * Source Documentation
  * What Lives Where
  * Important Classes & Modules
  * Coding Conventions
  * Testing Your Changes
  * Sending patches and committing changes
  * Using Git and StGIT
  * Building and releasing an engine
  * Copying an Engine Build into a Script
  * Missing History
  * Ancient Versions
  * Upgrading PLT
  * libxml2 Hacks
  * Upgrading wxWidgets

History
-------

  Halyard has its roots in a 16-bit DOS laserdisc application, and
  earlier multimedia-program-specific runtimes before that.  The
  current code base contains fragments dating back to at least 1993
  and perhaps earlier.  Before 2003, it was named 5L; from 2003-2008
  it was name Tamale, with many references to 5L still left, and in
  2008 it was renamed to Halyard.

  Halyard has been worked on by many programmers over the years.  One
  of the most prolific programmers in the late 90s and early 2000 was
  Chuck Officer.

Checking Halyard Out of Git
---------------------------

  To do an initial pull from Git, run:

    git clone git://imlsrc.dartmouth.edu/halyard

  If you want to be able to build Halyard on Windows, you'll also need to
  run:

    cd halyard
    git submodule init
    git submodule update

  If you are one of the primary maintainers, you can run the following
  command to point 'git push' someplace useful:

    git config remote.origin.url ssh://imlsrc.dartmouth.edu/var/lib/git/halyard

Downloading Halyard
-------------------

  You may download Halyard from:

    http://iml.dartmouth.edu/halyard/dist/

  Each halyard release contains several files:

    halyard-all-x.y.z.tar.gz     The full distribution, including all
                                 dependencies and media.  Most useful
                                 for building on Windows.
    halyard-x.y.z.tar.gz         Just the source code for Halyard itself,
                                 without the libraries it depends on.
                                 Most useful for anyone trying to port
                                 to the Mac, Linux, BSD, etc.
    halyard-libs-x.y.z.tar.gz    The libraries we depend on.
    halyard-media-x.y.z.tar.gz   Test media for running the test program.

  If you download the core halyard distribution and one or both of the
  other tarballs, you can untar them all in the same directory to merge
  them together.  For example:

    $ curl -O http://iml.dartmouth.edu/halyard/dist/halyard-0.5.4/
    halyard-0.5.4.tar.gz
    $ curl -O http://iml.dartmouth.edu/halyard/dist/halyard-0.5.4/
    halyard-libs-0.5.4.tar.gz
    $ tar xzf halyard-0.5.4.tar.gz
    $ tar xzf halyard-libs-0.5.4.tar.gz
    $ ls halyard-0.5.4/libs
    Makefile.am  freetype2      plt        quake2  sqlite3-plus  wxcode
    boost        libivorbisdec  portaudio  sha1    wxIE
    curl         libxml2        qtcheck    sqlite  wxWidgets

Building Win32 Halyard
----------------------

  Install Visual C++.NET 2005 off of the Microsoft Campus Agreement.
  Make sure you have everyting related to C++ development, but you can
  turn off all other parts of Visual Studio (like SQL server, C#, and
  all that junk).

  You will need to install the DirectX _9_ SDK, because certain
  libraries have been moved out of the platform SDK into DirectX.
  More recent versions of the DirectX SDK are incompatible with
  Windows 2000. You can find the DirectX 9 SDK in Subversion, at
  tools/build/dx9sdk.exe. Install it into C:\sdk\dx9\.

  Next, download and install the QuickTime 7.3 SDK.  This can be found on
  Apple's web site, at <http://developer.apple.com/quicktime/download/>,
  and if not there, then under tools/build/.  Install it using the bundled
  installer.  Make sure QuickTime is installed as well, including the VP3
  codec. The best way to install the VP3 codec is to run the installer of
  one of our existing programs, such as VTRA.

  You will also need Windows SDK version 6.1 (which is officially known as
  "Windows SDK for Windows Server 2008 and .NET Framework 3.5").  This is
  available from the Microsoft website at
  <http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en>.
  You can use the web-based installer, and you can omit the documentation
  and samples.  You _will_, however, probably need to install the core .NET
  tools.  Halyard doesn't use these, but Visual Studio apparently needs
  them.  The total download is about 650MB.

  Next, you must configure Visual Studio to use the Windows SDK.  Normally,
  you can just do this by running Microsoft Windows SDK v6.1 > Visual
  Studio Registration > Windows SDK Configuration Tool.  But if you have
  Visual Studio 2008 installed, you'll also need to (1) use regedit to fix
  a broken registry key, and (2) run WindowsSdkVer.exe in command-line mode
  if you want to register the SDK with Visual Studio 2008.  See the
  following two links for detailed instructions:

    http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/62b7d1a6-5210-4f1e-8fc5-a06193edce22/
    http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/7d0eafe5-477b-40cc-85a1-cd6296c6b745

  Note that Visual Studio 2005 can't be configured using the command-line
  version of the tool (although the undocumented -legacy flag to
  WindowsSdkVer.exe might help).

  Open up $HALYARD_DIR\Halyard.sln. Select Tools > Options > Projects
  and Solutions > VC++ Directories, and add the follow directories to
  the end of the list in the following categories:

    Include files:
      C:\Program Files\QuickTime SDK\CIncludes
      C:\sdk\dx9\Include
    Library files:
      C:\Program Files\QuickTime SDK\Libraries
      C:\sdk\dx9\Lib

  Click on "Solution Explorer", right-click on "Application", and
  select "Properties" > "Configuration: Debug".  On the left pane,
  under "Configuration Properties" > "Debugging", set the "Working
  Directory" to $HALYARD_DIR/test (the actual path, not the variable
  name!).  Select "Configuration: Release" and set "Working Directory"
  to the same value.  Now you'll automatically run Halyard/test when
  you ask Visual Studio to launch your program.

  Using a similar process, set the working directories for both versions of
  "CommonTest" to $HALYARD_DIR/Common/test.  The test suites won't run
  without this step. Also add "--wait" to the command arguments of
  CommonTest, in both the debug and release builds, so you can see the
  results of the test suites.

  To build PLT Scheme, make sure "Libraries" is selected in the "Solution
  Configurations" popup on your toolbar.  Choose the menu item "Build" >
  "Build Solution".

  Make sure "Debug" is selected in the "Solution Configurations" popup on
  your toolbar. In the "Solution Explorer", right click on "Application"
  and select "Set as StartUp Project". You should now be able to build and
  run Halyard by clicking on the "Start" icon. If you want to build a
  component without running it, you can select "Build <component>" from the
  build menu, or add the build button to your toolbar by right clicking on
  the toolbar and selecting "Build".

  To build the release version, select "Release" from the "Solution
  Configurations" popup on your toolbar and follow the same steps as
  above.

  To run the test suites, right click on "CommonTest" and select "Set
  as StartUp Project". Make sure the appropriate configuration is
  selected, debug or release. You'll need to run each of them before
  each check in.

Rake
----

  In order to build released version of the engine or install new engines
  in a program directory, you'll need to install ruby and Rake. Install
  ruby from Cygwin, install RubyGems from <http://rubygems.org/>, set your
  RUBYOPT environment variable to rubygems, and run 'gem install rake'.

Building Mac OS X Halyard
-------------------------

  There is an experimental Mac port of Halyard.  It is in rapid
  development and depends on many libraries, so for ease of updating
  the build documentation, it hosted is on the wiki.  See
  http://iml.dartmouth.edu/halyard/wiki/index.php/Building_on_Mac_OS_X
  for Mac OS X build instructions.

Source Documentation
--------------------

Halyard is documented using doxygen, an excellent, open source
documentation generator for C++.  You can get beautiful documentation
for the entire codebase--with diagrams--by installing and running
doxygen.  See doc/README.txt for details.

You can also configure doxygen to generate annotated, cross-referenced
source code and call graphs.

What Lives Where
----------------

  libs/                  - 3rd-party libraries
  libs/freetype2/        - 3rd-party font engine
  libs/plt/              - MzScheme interpreter, etc.
  libs/wxWidgets/        - Portable GUI library
  libs/...               - Lots of other stuff

  Common/                - Shared, portable code
  Common/Scripts/        - Test scripts
  Common/fonttools/      - Font-related programs (some are Linux-only)

  test/                  - Our official test and example project

  runtime/               - Runtime support files, including binaries
  runtime/collects/      - Scheme language runtime support
  runtime/ruby/          - Tools and libraries for managing Halyard projects
  runtime/fonts/         - Unix-style fonts for FreeType 2
  runtime/templates/     - Files to copy into a new Halyard project

  wx/                    - Front-end based on wxWidgets, intended to be 
                           portable, but currently only running on Win32
  wx/MSVC                - MSVC project files
  wx/gui                 - DialogBlocks source files for dialogs
  wx/src                 - Source code to new front end
  
  tools/                 - Tools used for Halyard and Halyard programs

Important Classes & Modules
---------------------------

  * TCommon.h, TPlatform.h
    - Lots of defines and portability stuff.

  * TPoint, TRect
    - Fairly featureful points and rectangles.

  * FileSystem, GraphicsTools
    - New portable libraries for pathnames and graphics.  Use these.

  * Typography, TStyleSheet
    - Portable, anti-aliased text service based on FreeType.  Not as
      nice as pango, but it doesn't require nearly as much support code.

  * TException
    - Parent class of most exceptions.
    - Use exceptions for error-handling in new code.
    - Not all old code is exception-safe, so be careful.
  
  * TLogger
    - The logging and error-reporting subsystem.
    - Use this if you need to abort the program, or show errors to the user.

  * TInterpreter
    - Abstract interface to interchangeable interpreters.
    - Subclass this to add a new language.

  * TInterpreterManager
    - Manages interpreters and implements script reloading.
    - Subclass this to add a new language.

  * TPrimitives, TCommonPrimitives, TWxPrimitives, etc.
    - Implementations of the actual Halyard commands.

  * TStartup
    - Initializes the Common library.

  * HalyardApp
    - wxWidgets application class

  * StageFrame
    - Our main GUI frame

  * Stage
    - The actual spot we display content

  * Element
    - Superclass of independent objects which appear on stage

  We have merged the old Macintosh and Windows code into a portable
  engine based on wxWidgets.  This process began in early 2002.

Coding Conventions
------------------

  The Halyard source includes a wide variety of coding styles.  In
  general, you should either (1) immitate the locally-prevailing style
  when making small changes to existing code or (2) use the officially
  approved coding style (below) when making big changes or writing new
  code.  Please DO NOT use non-standard styles in new code; the tree
  is inconsistent enough as is.

  For a small example class (showing reasonably good style), see
  Common/TException.{h,cpp}.

  All files should begin with the following comment, which should make
  Emacs Do The Right Thing<tm> on most systems:

    // -*- Mode: C++; tab-width: 4; c-basic-offset: 4; -*-

  Tabs are four spaces wide, blocks are indented four spaces, and braces
  always appear on their own line.  The keywords "public:", "private:" and
  "protected:" should be flush with the "class" keyword, not indented an
  extra level.  Continued expressions should be indented Emacs-style:

  int long_name = munge(really_long_name,
                        another_really_long_name);

  Global variables are named with a "g" prefix, static variables with an
  "s" prefix, and local variables with an "m" prefix (although a few
  classes use different conventions, and it's best to follow conventions
  within a class--I've seen both "m_" and "its" prefixes).  Input
  parameters have a "in" prefix, output parameters have an "out" prefix,
  and input/ouput parameters have an "io" prefix.

  Publically-visible names use lowercase interior capitals and no
  underscores (i.e. studlyCaps).  Functions names should have initial
  capitals; variable names shouldn't.  Local variables may optionally use
  all lowercase names with internal underscores.  Preprocessor macros
  follow the usual convention.  Examples:

    MyClass
    GlobalFunction
    gGlobalVariable
    mMemberVariable
    sStaticVariable
    inInputParameter
    outOutputParameter
    ioInputOutputParameter
    local_variable
    PREPROCESSOR_MACRO

  Class and method comments should obey Doxygen conventions and match
  the surrounding code.

  Code is 79 columns wide or less!

Testing Your Changes
--------------------

  We have two test suites: "TestAll", which is a fully-automated,
  low-level test suite (as advocated by the eXtreme Programming
  folks), and "halyard/test", an interactive, high-level test script
  written in Halyard.

  * Updating "TestAll"  

  Let's say you've added a new data structure, FooList, to the Common
  directory.  You should create a file named "FooListTests.cpp", and fill
  it full of tests.  Take a look at TStringTests.cpp for a good example.
  There's an art to writing good tests: You get all the common behaviors
  and corner cases, but you shouldn't write zillions of tests which prove
  nothing.

  For bonus points, write your tests *before* adding new features.

  Hook your test cases into TestAll.cpp.  You can figure out how to
  do this by looking at the source.

  * Updating halyard/test

  Unfortunately, "TestAll" still can't test lots of things:
  primitives, graphics, platform-specific code, etc.  In these cases,
  add one or more new cards to halyard/test and hook them into the
  main menu.  In order to test changes you've made to the Runtime
  directory, make those changes in $HALYARD_DIR/test

  Be sure to include a good description of how to use your test card!
  Anybody at IML should be able to read instructions on the screen and
  tell whether or not the test card is working.  (We have lots of older
  test cards without such helpful documentation; these are real problems
  when testing.

Sending patches and committing changes
--------------------------------------

  Before sending in or committing changes, it's good to use the following
  checklist to make sure everything works:

  1) If you're using Git or StGIT to prepare the patch, make sure your
     name and email address are set up properly, so when you send the
     patch in, we can give you proper credit.

  2) Run 'rake test'.  This will build all versions of the application
     and run the test suites.  You can probably even get away with
     just 'rake test_debug', which will only build and test the Debug
     version of the test suite.

  3) Build and run the engine, and open the halyard/test script.  Jump
     to any relevant test cards, and preferably all of the unit test
     cards.

  4) If you're using Windows, MAKE SURE YOU SAVE YOUR WORKSPACE, or
     else Git won't know about any changes.

  5) Make sure you've issued all the necessary git add or git rm
     commands, and do a commit to your local repository.

  6) Send the patch to the mailing list
     <halyard-dev@iml.dartmouth.edu> for review.

  7) Once it has been reviewed, if you have privileges to push it to
     the main repository, you may do so.  Otherwise, just wait for a
     maintainer push it; you'll receive full credit.

Using Git and StGIT
-------------------

  See http://iml.dartmouth.edu/halyard/wiki/index.php/Git
  and http://iml.dartmouth.edu/halyard/wiki/index.php/StGIT

Building and releasing an engine
--------------------------------

  Halyard uses Linux-style version numbers.  That means versions have
  the form "X.Y.Z", where X is the "major version", Y is the "minor
  version" and "Z" is the "revision".  (Actually, there will sometimes
  be an extra number after the revision, if somebody is working on a
  branch).  X, Y, and Z count up from 0: 0, 1, 2, ..., 9, 10, 11, etc.

  Release series with an odd minor version number are considered to be
  development releases, where major API changes may be made, or major
  functionality added or altered.  Release series with an even minor
  version number are stable branches, where the majority of work
  should be on fixing bugs and stabilizing.

  1) Update Common/TVersion.h.  The version appears in two places.

  2) While there, check the copyright date; it should be of the form
     "1993-YYYY", where YYYY is the current year.  The lawyers like
     this to be correct.  You might also want to take a look at
     tools/fix-prologues.pl.

  3) Run 'rake libs', if there have been any recent changes to plt or
     any other libraries that are not in the normal build process.

  4) Run 'rake test'.  This will build all versions of the application
     and run the test suites.  'rake test_debug' is generally sufficient,
     as the build process will run both debug and release builds and test
     them automatically.

  5) Run the debug and release versions of the application, and look at any
     relevant halyard/test cards.

  6) Update $HALYARD_DIR/Release-Notes.txt.  You should have a line
     including the version number and date, copy any notes about API
     changes out of 'git log <previous-version>..', and include the
     output of 'git shortlog <previous-version>..'.  If it makes
     sense, you may want to to add some summaries of major patch
     series.

  7) Commit your changes, using the entry in Release-Notes.txt as the
     commit message.

  8) Tag your commit:

     git tag vX.Y.Z

  9) Push the commit and tag to the master repository:

     git push --tags origin master

  10) Perform a build:

     ruby buildfile.rb vX.Y.Z

  Here's the basic process in brief:

  $ git pull
  # Update Common/TVersion.cpp and Release-Notes.txt
  $ rake test  # or rake clean test if you're paranoid
  # Smoke-test GUI by hand
  $ git commit -a # Commit message is generally the contents of
                  # Release-Notes.txt for this release.
  $ git tag v0.5.4
  $ git push --tags origin master
  $ ruby buildfile.rb v0.5.4 # this will take a while

Copying an Engine Build into a Script
-------------------------------------

  Consult the Rakefile of any recent project for the latest Subversion
  gymnastics.  Basically, you need to replace the script's copy of the
  Runtime directory, the Fonts directory, and any *.exe and *.dll files
  found in Win32/Bin.

  The process looks something like this:

  $ rake rm_engine_dirs_and_commit
  $ rake update_engine TO=0.5.0
  # Smoke test...
  $ svn commit # ...appropriate arguments...

Missing History
---------------

  While preparing the open source release (and setting up the git-svn
  gateway), we did some significant history-editing of older revisions.
  Specifically, files matching the following regexes were removed from
  the Subversion repository using a custom version of svndumpfilter2:

    \.exe$
    \.dll$
    \.mcp$
    \.pdb$
    \.xSYM$
    \.tdt$
    ^public/5L/tags/tamale_test/pre-template-card-syntax-change
    Bin/Mac5L
    blowfish
    CryptStream
    libs/CrashRpt
    libs/netxx
    Mac/Utility/CGWorld
    Mac/Utility/CTextFileStream
    Mac/Utility/CTimer
    Mac/Utility/CTimerTask
    Mac/Utility/LTask
    Mac/Utility/UDeleteTaskQueue
    Mac/Utility/gamma
    Mac/Utility/MoreFiles
    Mac/Utility/CKeyFilters
    Mac/Utility/CPictDataFile
    Mac/Utility/CSIOUXAttachment
    Mac/Utility/CStack
    Mac/Source/CModule
    Win32/DibLib
    Win32/Crypt
    Win16

  These files are still available in public/5L (and possibly
  public/halyard), but only to internal users.  Many of the removals
  were necessary to get the git repo size down to a manageable level,
  and most of the rest were for copyright or export reasons.

Ancient Versions
----------------

  We shipped Genetics in Clinical Practice on top of an older engine (early
  2002) which has substantially more primitive build and testing procedures.
  Also, this engine exists in entirely separate Windows and Macintosh
  versions, with no shared code.

  You can find this engine in Subversion as FiveL_3_1_1_Stabilization and
  Mac5L_202_Stable.  Release notes are in Win32/ReleaseNotes.txt and
  Mac/ReleaseNotes.

Upgrading PLT
-------------

  Get the appropriately tagged version of PLT from the PLT Subversion
  server. You should probably do an svn export so you won't get any of
  the .svn directories. For example:

    svn export http://svn.plt-scheme.org/plt/tags/v360 plt

  Once you have that, follow the vendor branch procedure to import it
  to vendor/plt/current, tag it, and then merge that tag into
  halyard/libs/plt.

  Ten libraries (listed below) from libs/plt/collects need to be
  aliased at Common/Runtime.  When updating libs/plt, be sure to 'svn
  rm' the copies at Common/Runtime and use 'svn cp' to copy the
  updated versions over.  (If you're using a client with really fancy
  branching support, you could always use a star-merge instead.)

    compiler
	config
	mzlib
	net
	planet
	setup
	srfi
	swindle
	syntax
	xml

libxml2 Hacks
-------------

I made a static version of libxml2 for Halyard by cloning the "Win32 Debug"
and "Win32 Release" targets to "Win32 Debug DLL" and "Win32 Release DLL"
respectively, then opening up the DSP file in Emacs.  After the TARGTYPE
line:

  # TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102

...I inserted a second target type:

  # TARGTYPE "Win32 (x86) Static Library" 0x0104

Then I edited the comments further down to read as follows:

  !MESSAGE "libxml2 - Win32 Debug" (based on "Win32 (x86) Static Library")
  !MESSAGE "libxml2 - Win32 Release" (based on "Win32 (x86) Static Library")

Then I re-opened the DSP file in Visual Studio and made the following
changes to each of the non-DLL targets:

  * Set the /nologo flag.
  * Set appropriate build and output directories.
  * Replaced the _USRDLL proprocessor define with _LIB.
  * Set a runtime library which matched my project.


Upgrading wxWidgets
-------------------

Get your copies of wxWidgets from anonymous CVS, *not* the tarballs or
zipped sources.  The tarballs are missing many files which are present in
CVS (including MSVC project files), and there's no practical way to find
them all except in a CVS copy of wxWidgets.  No, the wxMSW installer won't
work either--it's missing *other* files.

Upgrading wxWidgets is officially a pain in the neck, and typically takes
several days.  Here's my working outline from the 2.5.x -> 2.6.1 upgrade.
It should give you some sort of idea about what you're getting into.

  Steps
    Get it building
      Download 2.6.1
        MUST get from anonCVS, not tarball, if we want MSVC++ project files
      Extract patches we made to 2.5
        9 local patches found
      Back out patches as necessary
      Delete added project and setup.h files we'll need to regenerate
      Check line endings of 'cvs export' and new code
        Both appear to be DOS
        Let's hope it does the right thing
      Make a list of files deleted by upstream maintainers
        The list is huge so we don't keep a copy here
      Import 2.6.1 to vendor branch
      Resolve any import conflicts
        C libs/wxWidgets/contrib/include/wx/stc/stc.h
        C libs/wxWidgets/contrib/src/stc/gen_iface.py
        C libs/wxWidgets/contrib/src/stc/stc.cpp
        C libs/wxWidgets/include/wx/evtloop.h
        C libs/wxWidgets/include/wx/image.h
          Ooops, we were merged after all!
        C libs/wxWidgets/include/wx/msw/wx.rc
        C libs/wxWidgets/src/common/image.cpp
          Ooops, we were merged after all!
        C libs/wxWidgets/src/msw/bitmap.cpp
        C libs/wxWidgets/src/msw/dc.cpp
          Ooops, we were merged after all!
        C libs/wxWidgets/src/msw/dib.cpp
        C libs/wxWidgets/src/msw/evtloop.cpp
        C libs/wxWidgets/src/msw/textctrl.cpp
        C libs/wxWidgets/src/msw/window.cpp
      Make sure that 'cvs import' deleted files deleted by upstream maintainers
      Regenerate project and setup.h files we deleted
      Build Tamale
      Reapply local patches
      Add files to CVS
      Apply wxWidgets-2.6.1-Patch01.zip bugfixes to local tree
        I put them on the vendor branch; it was pretty tricky but worked
    Look for bugs
      Full-screen mode is broken
        Just a corrupt build
      Window backgrounds get erased when they shouldn't
        Examples
          ScriptEditor
            When opening a new document, it shows up first as a small
              subwindow, then resizes
          QuickTime
            Are we displaying the QT window as a blank black rectangle
              earlier than we used to?
        Must set up all object options *before* Create() gets called
          Create now draw objects immediately!
      Stupid flickering in DocNotebook tabs when opening new window
        Reported to the bug tracker
    Document process
  Analysis details
    Analyze patches from 2.5
      Back out completely
        wxWidgets-2.5-bitmap.diff
          Alpha premul moved to dib.cpp
          Multiple small bugfixes
          ALL CHANGES MERGED IN 2.6
        wxWidgets-2.5-dib.diff
          Alpha premul happens *here* now
          ALL CHANGES MERGED IN 2.6
        wxWidgets-2.5-image-bugfix.diff
          delete -> free bugfix
          MERGED IN 2.6
      Merged by upstream, but we didn't notice them the first time around
        wxWidgets-2.5-dc.diff
          Alpha blending fixes
          NOT IN 2.6
        wxWidgets-2.5-image-convertmask.diff
          ConvertMaskToAlpha function
          NOT IN 2.6
      Leave in place during merge
        wxWidgets-2.5-textctrl.diff
          Tab-order bugfix
          NOT IN 2.6
        wxWidgets-2.5-window.diff
          Support for using PERIOD key as part of a menu accelerator?
          NOT IN 2.6
      Back out and reapply after merge
        wxWidgets-2.5-evtloop.diff
          Broke out prologoue and cleanup of main event loop so we can
            override it safely
          NOT IN 2.6
          This code needs to be rewritten, preserving only the API (the
            internals have changed)
        wxWidgets-2.5-wxrc.diff
          Workaround for MSVC++ "project always dirty" bug
          NOT IN 2.6
          Small changes to nearby code
          Is this still necessary?
        wxWidgets-2.5-stc.diff
          Bugfixes
          Improved LISP support (including some hacks of local interest only)
          NOT IN 2.6 - Messy hand merge required
          Look for local problems in LexLisp.cxx--the API has changed
          May have actually fixed string lexing bugs
    Files we added to 2.5
      Project files
        build/msw/wx_wxexpat.vcproj
        contrib/build/stc/stc.vcproj
        contrib/build/xrc/xrc.vcproj
        contrib/utils/wxrc/wxrc.vcproj
        src/wxWindows.vcproj
        src/jpeg/jpeg.vcproj
        src/png/png.vcproj
        src/regex/regex.vcproj
        src/tiff/tiff.vcproj
        src/zlib/zlib.vcproj
      Setup headers
        include/wx/setup.h
        include/wx/msw/setup.h

And while you're at it, don't forget to set wxUSE_DISPLAY to 1 if you want
screen-resizing support.