Goals of the Investigation and Areas of Concern ---------------------------------------------------------------------- ROOT is a complex product that must be supported and developed on several UNIX platforms and Windows NT. This short paper attempts to examine support issues on the windows nt platform. This includes the following: - Code Development Issues - Maintaining parity with the UNIX version - Features unique to the NT platform - Testing - Support Issues - Manuals or other unique by products for windows NT - Distribution and installation - User support issues The biggest area of concern is that the current ROOT team does not have a Windows NT member. This is someone whose job is to keep new versions and features of root building on the Windows NT system. At first blush this does not seem to be a very bad thing: a new Windows NT expert can come on at any time, work hard, and recover the lost ground. The real difficulty is that the primary developers of ROOT are UNIX centric and with out a NT expert at their shoulder they make decisions that are UNIX centric and may be unnecessarily difficult to implement on NT. This is issues has been brought up by both the current developers and by Valeri. In fact, the current version of ROOT on UNIX has a completely revamped version of the GUI that is lacking on NT at the moment due to the lack of a person. - Code Development Issues -- Maintaining Parity with the UNIX version There are, traditionally, two big areas of work that must occur when porting a program from UNIX to Windows: the GUI and the file system. The file system work is relatively minor and in the case of ROOT has already been completed. The ROOT authors have made an attempt to isolate most functionality in a few abstract classes to ease porting issues. The current version of ROOT on NT has the ROOT version 1.0 GUI. Implementing the version 2 will require a complete rewrite. Care must be taken in its design. The normal windows application spends most of its time waiting for input from the screen. In fact, its central processing loop revolves around a call that fetches a keyboard, mouse, or other event. This is different from the basic ROOT philosophy that waits in the standard C i/o routines for the next line of input text to CINT. In particular the design should not suffer from the version 1 design flaw: root would GPF (core dump) when you requested a plot if a canvas and window weren't already displayed. This means that the solution will almost certainly have to be multithreaded. While windows does have an extensive class library to help one build a GUI application (MFC -- Microsoft Foundation Classes), it is unlikely it can be used for this purpose as ROOT much be able to run in batch mode, with no GUI attached. The new GUI uses an abstracted class, TGXW (http://root.cern.ch/root/html/TGXW.html). It has over 150 methods that do the drawing from a very primitive level: drawling, DrawRectangle. There are also some higher level functions like FillPolygon. This class also has all of the window manipulation routines in it, like ResizeWindow. The implementation file for X11, TGX11 is huge: about 2500 lines long. All the parameters are typed, like window handles, pixel map handles, color map handles, font handles. However, it is hard to imagine that the UNIX world will map directly into the Windows world. Without several days of work it is difficult to understand how this might effect the creation of the TGWin32 class. The other option is to use a X11 implementation on Windows NT. The X11 implementation for the new GUI has already been completed and so this may be less work. There are two routes: commercial and freeware. The commercial route is not in keeping with the current root philosophy, and so was not further investigated. There are known freeware implementations. For example, NIRVANA uses a freeware version of X11 on NT to provide its graphics. The product used by NIRVANA is based on cygwin32, which is a UNIX look-alike that is run on Windows NT. cygwin32 is currently being used to develop software at D0 as well. The bad point here is the extra work that is involved in getting a version of root up and running on a user's PC. Three independently developed products must now work in concert. This solution does not appear to be tenable for this reason. -- Features Unique to Windows There are several features which are quite important to have in root on the Window's platform, and perhaps on UNIX. First is the ability to copy a graphics image from a ROOT window into the Windows clipboard. This enables one to directly paste plots into web page editors as well as email or other low quality documents. This does not alleviate the requirement of a postscript producing option, as that is the only method of getting a high resolution document at the moment. If it is possible to cut and past a postscript file with a preview (much as ghostscript produces) then this should be viewed as the most developed version of this feature. Direct printing is another important feature that should be present on any root window. This does not amount to more than selecting print and having the current window appear on a printer. Clearly, this is most important for the graphics windows. There are numerous other features that one would like to see in ROOT, but the above two go a long way to integrating ROOT into the Windows environment. Should people have spare time one can imagine making ROOT an ole container so that a root macro and its graphical output can be placed in a document or it can be easily controlled by another application (like a web server). This, however, is most likely as much or more work than the implementation of the GUI and clearly must less important. -- Testing As has been pointed out before, rigorous testing procedures for ROOT are lacking. This is important for all platforms, but is very important for a platform on which the primary development is not occurring. This is a large effort, however, since this isn't a Windows NT only issue it won't be focused on here other than to point out how it can significantly help the developers maintain their code bug free on the Windows platform. - Support Issues Due to the number of physicists associated with Fermi it is likely that support will be a long term issue for ROOT. It is likely, however, that most all of the support for UNIX and NT will overlap and no extra work will be required. -- Manuals or other unique by products for windows NT Presumable small manuals will have to be written. This will include special issues that are individual to the experiments as well as global to Fermilab. It is expected, however, that the extra pages for issues global to Fermilab will be small, on the order of 10 pages or less. -- Distribution and installation There are two ways to distribute ROOT for Windows NT at Fermilab and to its other uses. ups/upd does work on Windows NT and that could be used. In fact, for the machines local to Fermilab this may be the desired distribution method as the potential for automatic update is enticing. However, Fermilab users away from Fermilab may not wish the overhead that comes with a ups/upd installation (again, cygwin32, perl, etc.). In this case a distribution much as how ROOT is current distributed may be required. Another possibility is to use a commercial product like InstallSheild, an automatic installer for the Windows platform. Because root has been redesigned with a front end so that only a single environment variable is required for it to run, it is imagined that any installer will be quite simple: it will have to define ROOTSYS and also extend the PATH variable to include the \bin directory. -- User support issues The people who must answer email and accept phone calls from users requesting help on ROOT should be versed in all the platforms it runs. Further more, there should be designated experts on all the platforms that can be turned when the support personnel can't answer the question. This will be difficult if support drops to one person, as it did for CERNLIB towards the end of Run I. Recommendations to Address the Areas of Concern ---------------------------------------------------------------------------- The most immediate thing that must be done is a Windows NT person working on the ROOT development team. It is also recommended that a method of converting the UNIX make files into IDE files be found that has minimal impact on UNIX development be found. GUI classes based on the abstract TGXW class should be written. Windows developers should understand the direction ROOT is going in and see what the advantages the windows platform can bring. This includes implementing features commonly found in other windows programs like printing and copy/paste. Features like this also make the program simpler to use on the UNIX platform. Lastly, the person assigned should be assigned to this task in the long term so that they may develop a good working relationship with the other code developers. Tasks to be Accomplished (with their relative benefits) to Achieve the Recommendations ---------------------------------------------------------------------------- This section is mostly a repeat of the last section Move cmz to make. - Good: - Allows easy tracking with the UNIX version - Bad: - IDE creation is difficult. - Most likely will have to find a version of make that runs standalone or install cygwin32 to do code development. Package the product for distribution - Good: - Availible to the general user right away - Bad: - Distributing the old version of the product; support issues Find a way to product a set of IDE files from the UNIX make file - Good: - Working with the IDE is much productive on Windows that working with the command line; it is pretty much the only way to access the debugger. - Bad: - May impact how the UNIX makefile is structured - Will take some time! The IDE is put above the GUI only because it can be very difficult developing on Windows without using the IDE. However, if the developer does not feel this is required, this can be put off to a later time. Get the new GUI implemented - Good: - Gets Windows and UNIX in sync, which will decrease support issues - Fermilab will have many cross platform users. - Bad: - There are almost no downsides to this as long as you accept that the Windows NT version of ROOT should continue to move forward with the UNIX version. Implement Windows Features - Good: - Better integration into the Windows environment makes ROOT simpler to use. - Improvements unique to Windows can be carried back to UNIX to further improve that version. - Bad: - Potential to get out of sync with UNIX version. ---------------------------------------------------- Cost of Accomplishing the Tasks - $ and FTEs FTE estimates: Move cmz to make: Same as for UNIX version Package the product for distribution: 1 week given familiarity of distribution tools Find a way to product a set of IDE files from the UNIX make file: 1 month Get the new GUI implemented: 2 months, faster if familiar with raw Windows GUI API. Implement Windows Features: 1 month for each one It must be noted that some of these estimates are guesses: the author has never tried to program to the Windows API directly!