# Platform Notes

## X Window System

The current X Athena implementation of V uses the Athena widget set with some modified versions of some widgets from the Xaw3d widget set. These modifications can conflict visually with the standard Xaw3d widgets, so applications may not look ideal if libXaw3d is used.

The Motif version was developed with LessTif, and you must use at least LessTif version 0.88.

### Compilers

The `makefile` provided with V uses the GNU C++ compiler, `g++`. V does not use templates or other C++ features that can cause portability problems. The current version has been built and tested using `g++` Version 2.8 although it did work back to Version 2.6.3, but not earlier versions. There is no inherent reason that V should not compile with other C++ compilers.

### The X Makefile

The `Makefile` is the main way to build X versions of V. It has comments that should help you to build the X version of V. See the Installation for more instructions for installing V on a *nix platform. All of the customizations for a given platform have been isolated into one of the configuration files `Config.mk` in the `/v/Configs` directory.

V has successfully been compiled on most current X platforms available, including Linux, SunOS, Solaris, AIX, SGIs, and DEC Alphas. The standard distribution includes a `Makefile` that can be easily configured for these platforms. The makefile requires GNU make! The secret is to examine `Config.mk` and add and modify the definitions at the beginning as needed for your platform. (For Linux, this will usually be a no op, since Linux is the default configuration.) Examine the definitions already there, and then add a section with the locations defined as needed for your platform. Then use an `ARCH=` definition on the `make` line (or make your platform the default.)

### X Resources

V makes limited used of X resources. The main use is to define the basic color schemes for the ATHENA version of controls and dialogs. The following resources are used:

vDialogBG
  The color used for the background of dialogs and command bars.

vStatusBarBG
  The color used for the background of the status bar.

vMenuBarBG
  The background color of the menu bar and menu drop downs.

vControlBG
  The background color for some controls, such as sliders and scroll bars.

vControlFace
  The color used for the faces of various controls such as buttons.

vLightControlShadow
  The color used for the light shadow on 3D controls.

vDarkControlShadow
  The color used for the dark shadow on 3D controls.

By varying just the above X resources, you can really change the visual look of your V app. The `/v/srcx` directory contains several files of the form `vRes*` that contain various color schemes. The default color scheme is contained in `vResDefault` (but you don't need to load it - it is the default). The file `vResBlueMtf` contains the color scheme similar to Motif. This is the contents of `vResDefault`:

    *vDialogBG: gray75
    *vStatusBarBG: gray80
    *vMenuBarBG: gray70
    *vControlBG: gray80
    *vControlFace: gray70
    *vLightControlShadow: gray87
    *vDarkControlShadow: gray50

To use one of these, or your own, resource files, you can use the command `xrdb -merge vResColorscheme`. You can also add the lines to your `.Xresources` file. This works only for the Athena version.

For the Motif version, the easeies way to control how things look is with the `-bg` background switch when you start the application. For example, if you started VIDE with the command `vide -bg gray75`, all the controls will be based on the gray75 color, and gives a very nice result.

The X program name is the name you supply to the `vApp` constructor.

### X Bugs

The PostScript print driver does not draw shapes with hatched brushes.

The PostScript drawing canvas does not support `CopyFromMemoryDC`.

Source code uses two naming conventions - `.cxx` and `.cpp`. Gnu g++ version 2.6 and later support both file extensions. G++ version 2.5 doesn't like `.cpp`, so you might have to rename those files to `.cxx`,

There seems to be problems with colors on X Pseudocolor systems.

## Microsoft Windows

The current implementation of V for MS-Windows is for Windows WIN32 (Windows 9x and NT). As of V 1.21, official support for Windows 3.1 has been dropped. It is unknown if V actually still works or not on 3.1. We will refer to this version as `Vwin` in this description. The Windows version of V is available in the standard distribution tar file on the V ftp site. You will need a version of `gunzip` and `tar` to extract V. These are available on the ObjectCentral ftp site as well.

### Directories

The directory structure of V under MS-Windows is similar to the X version. On the distribution, the MS-Windows hierarchy is found under the `/v` directory. (We will use Unix / notation for files instead of the usual MS-Windows backslash notation. Most MS-Windows compilers handle the / correctly, and / is used throughout the V source files.) When you unzip the archive, a subdirectory `/v` will be built.

Under `/v` are `/bin/win` for the example V MS-Windows binaries, `/draw` for the VDraw example program, `/examp` for a simple example program, `/includew/v` for the V `.h` header files, `/lib/win` for the MS-Windows compiled library, `/obj/win*` for the object files, `/srcwin` for the MS-Windows version of the source code, `/test` for the test driver program, and `/tutor` for the source code to the tutorial included in this reference manual.

For MS-Windows, the V library source files use a `.cpp` extension. The example programs also use `.cpp`. The source for most of the example programs is identical for the MS-Windows and X versions! However, the source for the library `.cpp` and `.h` files are different for each platform, so you must be careful not to mix the X and MS-Windows versions of source code and header files.

### Compilers

V has been successfully been compiled using Borland C++ 4.5 for Win3.1 and WIN32; Borland C++ 5.02 for WIN32; Watcom 10.6 for Win3.1 and WIN32; the GNU-WIN32 gnu g++ compiler (both with Cygwin and mingw32); and Microsoft VisualC++ under several versions. See the Installation notes for more specific information about the various compilers.

Several Borland `.ide` files are included on the directory `/vwin/bccide`. The `.ide` files assume V is built on drive C:, so you may have to modify it if you want to build V on your own system. If you are using another compiler, then you need to compile every `.cpp` file found on the `/srcwin` directory.

Project files for compiling with Watcom C++ are included in the directory `v/watcom`. Unlike the Borland versions, the object code and libraries are built directly on these `watcom` directories.

The required changes and makefiles required for the `mingw32` compiler will be made available on the Vweb site.

### MDI/SDI Models

V for MS-Windows supports both the MS-Windows MDI and SDI models. By default, V uses MDI, and will bring up the main MDI window, and open the first MDI child window. There currently is no way to have a main MDI window with no active MDI child windows - when you exit the last window, the application closes. The menu, command bar, and status bars will change to the ones defined by each child window as each child window is activated.

V will automatically append a `Window` menu item to the main menu. The built in `Window` menu supports the standard cascade and tile MDI operations, as well as showing a list of MDI children.

You can also get MS-Windows applications to look like the standard SDI model. If you want an SDI app, you control this in the static declaration of the `vApp` object:

      static testApp* tApp = new testApp("Vtest",1);

The second parameter controls MDI or SDI. A default parameter is defined by Vas 0 to indicate the MDI model. If you specify a 1, then Vwill take an SDI look. It actually does this by using the MDI code, but maximizing the canvas window, removing the extra buttons from the menu bar, and not adding the `Window` menu. It is impossible for the user to tell that this is really an MDI application, but Vdoes not strictly enforce this. If you create more than a single `vCmdWindow` object, unpredictable things will happen under the SDI simulation. It is up to you to not do that.

Since X doesn't have an MDI/SDI equivalent, it is harmless to specify SDI to an X version of your app.

### Icons

As stated in the main part of this manual, V does not use resource files. This is true for the MS-Windows versions. However, there is one reason you might want to include a `.RC` file with a V MS-Windows application, and that is to allow you to define the icons used with the application. (These are MS-Windows icons, and are not the same things as `vIcons`.)

Typical MS-Windows MDI applications use two icons - one for when the whole application is iconized, and one when each child window is iconized. If you don't supply a `.RC` file, you will get the default MS-Windows icons. The V distribution supplies two default icons of its own, called `vapp.ico` and `vwindow.ico`. By including the definitions `vAppIcon` `ICON` `vapp.ico` and `vWindowIcon` `ICON` `vwindow.ico` in the `.RC` file, V will load and use those icons for the application and each child window respectively. You can substitute whatever two icons you want for your application by specifying different `.ico` files for the `vAppIcon` and `vWindowIcon` names in the `.RC` file.

### DEF File

MS-Windows applications are typically compiled using a `.DEF` file. You can modify any of the `.DEF` files included with V sample programs.