What is Pascal?
Pascal is a language high-level developed by Niklaus Wirth in the late 1960s. The language is named after Blaise Pascal, a seventeenth-century French mathematician who constructed one of the first mechanical adding machines.
Pascal is best known for its affinity to structured programming techniques. The nature of the language forces the programmer to design programs methodically and carefully. For this reason, it is a popular teaching language.
Do not use longint variables in procedures that you declared INTERRUPT
Turbo Pascal uses 32-bit registers for longint arithmetic if it detects that it runs on a 80386 processor (or higher), but procedures declared INTERRUPT do only save the 16-bit registers. So if a longint arithmetic was interrupted by such an interrupt, the result of the calculation will be garbled. Solution: either set the variable test8086 to 1 or save the 32-bit registers yourself.
Do not use the reserved word INTERRUPT to declare interrupt procedures if your interrupt procedure uses stack (i.e. it has local variables or calls other procedures)
In procedures declared INTERRUPT the Turbo Pascal compiler automatically adds code to store the processor registers on the stack before the procedure starts and restore them before it ends. However during the interrupt your program does not use its own stack, but the stack of the program that has just been interrupted and the stack is guaranteed to have room only for very few bytes. If you need more stack, use my trapping unit.
EMM386: DMA mode not supported
This error message may mean what it says: you used a DMA mode that is not supported by EMM386 (mem to mem mode). However sometimes that error occurs when you did use a legal DMA mode. What Microsoft does not tell is that this message also occurs if you use several DMA transfers in sequence and you don't always use the SAME DMA buffer. So don't allocate a DMA buffer when needed and release it when ready, instead allocate the one and only DMA buffer when the program starts and use this buffer for all DMA.
For some cases is it usefull to have your systemdate in a certain form. This function returns the date in the german format DD.MM.YY, but I think there is no problem to change this.
This function returns the time of your system in the form HH:MM.
Dump window Fix up
During debugging, it is sometimes necessary to watch a memory location in the Dump or CPU windows. This is fine as long as you want to watch one address, where you just press Goto (Ctrl-G) and then the address or variable you want to dump.
It is also possible to always watch a certain variable or have the dump window refer to an address in a register - very useful. To do this, use the Fixup item on the local menu and type an address expression such as "eax", "P" or "@MyVar". The dump window then "follows" the value of the expression.
Making use of Virtual Pascal Options (VPO) files
When working on multiple projects in Virtual Pascal, save the settings for each (directories, compiler settings, etc) in separate .VPO files using the Options->Save Options menu item.
On the desktop, create multiple VP objects or shortcuts, and enter /C[Name of VPO file] in the Parameters section. You now have easy access to all of your projects and do not have to load the options every time you start VP. This is also useful when creating a build process. The command line compiler VPC can use the IDE's VPO file as input - making it easy to maintain a single source of settings. Just specify VPC /V[Name of VPO file]!
Help window feature
In the IDE, pressing Ctrl-F1 brings up context-sensitive help for the topic under the cursor. Once in the help system, Ctrl-F1 does nothing.
Instead, point the mouse to the word you want help for and use Ctrl+Right mouse button. This also brings up context-sensitive help and works both in the editor and in the help window.
This setting is defined in the Options->Environment->Mouse dialog and can be changed to "Inspect", "Evaluate", "Search", etc as you desire.
One of the much-used features of the IDE is the Search function in the IDE, accessible either by Selecting Search->Find, or by pressing Ctrl-QF. Another very useful feature is the Incremental Search, which is not found in Borland Pascal. To use it, select Search->Incremental Search and type in your search string; the line with the "best hit" so far is highlighted. The search can be aborted by pressing ESC.
To avoid having to go to the menu every time, the obvious solution is to record a macro doing it for you: Select Options->Macro->Create, select Alt-I (or whatever) for the key, and type Alt-S, I. These two keystrokes are now in the macro buffer, but we cannot *end* the macro recording! Pressing Alt- or selecting Options->Macro->Stop does not work, because the incremental search is still going. Solution: Press ESC to stop the incremental search, and stop recording the macro. The n go to the Macro definitions page (Options->Macro->List) and highlight the new macro. Tab across to the right-hand pane and *delete* all keystrokes in the macro after the Alts and I characters, so the macro consists of only those two keystrokes. Having done that, exit the macro list and you have an easy way of doing incremental searches :-)
This may all sound a bit complicated at first, but it really is not. Try it!
Undo buffer flush
When working with the Virtual Pascal IDE, you have an "unlimited undo" facility. This means, that whatever you did (excluding clipboard operations that is) at any point in time can be undone. This includes cutting 50000 lines of text and pasting it back in somewhere else - and this obviously can take up a lot of memory.
Unfortunately, there is no option to flush the Undo buffer (Might introduce that one at some point though), so it is advisable to exit the IDE and restart it once in a while - say, every 4-8 hours or so, depending on what you do. Of course, if all you do is write source code, it is not important, since 50k hardly matters. Many big block operations can quickly get you into the MB range though, and this can impact on the performance of OS/2.
Update: It is possible to "fool" the IDE to do a flush of the Undo buffer. If you occasionally use the "Redo" feature, VP flushes the part of the Undo buffer when more changes are made after a "Redo".
In the Virtual Pascal IDE, select View > nits or press Shift-F3 to get a list of all units (including include files) in your program. Use the arrow keys to navigate the list, or use the incremental search feature by typing in a partial unit name. Units compiled with Debug Information enabled have a (+) next to them. This Press Enter on a unit name to open that unit - this is much easier than navigating multiple directories.
The Log window in Virtual Pascal is accessible by selecting View->Log. In addition to displaying information during execution (Breakpoints hit, threads starting and stopping), it can be used to determine which DLLs are being used by the program.
When running a program, or preparing it to run by pressing Ctrl-F2, the Log window lists the DLLs used by the program. This can be useful to determine whether your program relies on DLLs you were not aware of, such as a full-screen app using one of the PM DLLs. If this is the case, you may want to look at your Uses clause and clean out unused clauses to make the app run on systems that do not have PM available.
The content of the Log window can be logged to a file by selecting the local menu on the window (right mouse click or Alt-F10) and selecting Open Log File.
The debugger in Virtual Pascal can debug any 16- or 32-bit OS/2 executable, and any 32-bit Windows executable, not just the ones compiled by VP itself. Use the File > Load Program option to load any executable into the CPU window.
In OS/2, if a .SYM file is available for the executable or any DLLs it uses, the debugger can use these to display limited symbol information as well. Copy the SYM files to a directory and specify this directory on the command line preceded by /S, for example /Sf:\vp11\sym. When a SYM file is available, Virtual Pascal displays variable names instead of memory references, and indicates the beginning of named entrypoints and local functions by their names.
Try this with one of the OS/2 executables, such as FORMAT. As you will see, most of the command-line utilities are still 16-bit and compiled with Microsoft C version 6 :-(
Debugging OS/2 DLLs
It can sometimes be useful to determine exactly what OS/2 does when calling an API function, and special care needs to be taken when tracing into OS/2's DLLs. When doing this, it is a good idea to copy the SYM files from the OS/2 CD-ROM first - most OS/2 executables and DLLs come with the associated SYM files (See Tip #8 for SYM files).
You can safely trace into most OS/2 DLLs by using F7 (Trace Into), but using Trace Over (F8) will in many cases cause a total system lockup. This is because the Trace Over (And Goto Cursor, F4) function places a breakpoint at the desired location, by replacing the instruction with an INT 3 instruction (Hex $CC). While your process is on its way to the breakpoint, it is likely that another process (OS/2 itself, for example) reaches the breakpoint location, but does not have a debugger to transfer control to and does not know what to do with the INT 3 instruction - crash.
Of course, placing a Breakpoint (Ctrl-F8) is out as well, since this uses the same technique.