Home > Programming >

FAQ: BETA Programming Language (version 1.11 - 08 Dec 97)

Section 5 of 6 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6

problem in files of your own.

The solution is to split up the expression involving the division into
simpler expressions. Use option --traceCode to find out what expression is
causing the error.
----------------------------------------------------------------------------

C11.3) Bugs in version 5.2 of the compiler

Since the release of v5.2 of the compiler august 1996, the following errors
have been reported.

Some of these errors occur in very specific situations, that are hard to
describe in general, but others may be generally presented, please see
below.

C11.3.1) Strange error messages like "attempting to translate foo..db.bet"
[corrected in r4.0.1]

Some of the internal restructuring of the compiler that has been done for
version 5.2 has caused a new bug to appear. The symptom of the bug is that
.bet sometimes gets appended to the file name reported, when e.g. an attempt
to write a file fails because of permission problems.

An example is

You are attempting to translate the file
/users/smith/beta/private/sun4s/foobody..db.bet
You do not have permission for doing this!

in case the file /users/smith/beta/private/sun4s/foobody..db, or the
directory it resides in, is write protected.

There is currently no workaround for this bug, but it is usually obvious
what file name should have been reported.

C11.3.2) Errors when evaluating expressions involving reals and external
calls [corrected in r4.0.1]

On all supported platforms, using both reals and external (C) calls in an
expression may yield unpredictable results.

For instance the following program

ORIGIN '~beta/basiclib/v1.5/math';
--PROGRAM: descriptor--
(#
do (1->sqrt) -> putint; newline;
(10->log10) -> putint; newline;
(1->sqrt)+(10->log10) -> putint; newline;
#)

will give the (wrong) output

1
1
4

on Solaris. The only known workaround is to split up the expressions, so
that the parts that call the external functions are isolated (like the first
part of the above program).
----------------------------------------------------------------------------

C12) Tracing the work of compiler?

In the extremely rare event that the compiler crashes during compilation of
your program, you may yourself do some tracing of the compilation to find
out what particular part of your program, that makes the compiler crash. You
do this by specifying some compiler switches:

1. If the compiler crashes during *code generation* of a fragment, please
do this:

beta -s 308 311 0

This will make the compiler print out each declaration and imperative
just before code is generated for it. Thus when the compiler crashes,
you can see what part of your program caused it.
2. If the compiler crashes during *checking* of a fragment, please do
this:

beta -s 191 192 193 0

This will make the compiler print out each descriptor, declaration and
imperative just before checking it. Thus when the compiler crashes, you
can see what part of your program caused it.

In version v5.1 of the compiler, you can use the two new compiler switches
--traceCode and --traceCheck instead.
----------------------------------------------------------------------------

C13) Problem with floating point expressions in connection with repetitions
[fixed in v5.1]

The compiler does not generate correct code when floating point expressions
are used in the calculation of repetition ranges as in:

R: [FR1] ...
do ...
FR2->R.extend
FR3->R.new

where FR1, FR2 and FR3 are expressions yielding a floating point value. The
compiler should convert these floating point values into integer values, but
fails in doing so.

You can get around the error by explicitly converting the expression to an
integer value. If "I" is an integer variable, then the following will work:

R: [FR1->I] ...
do ...
FR2->I->R.extend
FR3->I->R.new

This problem have been fixed in version v5.1 of the compiler.
----------------------------------------------------------------------------

C14) New features introduced in the Compiler

C14.1> New features in version 5.3 of the Compiler

BUILD property
BUILD property now included in the BETA compiler. This replaces the use
of MAKE.
See the Compiler Manual p33 for more details.

Binary Object Files
The compiler now generates binary object files on Win95/nt (except for
Borland SDK). This eliminates the need for an external assembler.
Debug info
The compiler now generates debug info on Win32 platforms. This enables
the debugger, Valhalla, to work.
Gnu
The compiler now supports gnu as SDK. This makes personal use
completely free on Win32.
SGI: IRIX 6.x
SGI: IRIX 6.x is now supported (see however SG04).

C14.2) New features in version 5.2 of the Compiler

The following new features have been implemented in version 5.2 of the
compiler, compared to version 5.1.

New Platforms
Much effort has been put into porting the compiler onto new platforms:
o A final version for Silicon Graphics MIPS is now available.
o The Linux compiler now generates binary code directly.
o Work is ongoing to make a binary compiler for Windows NT and
Windows 95.
o Work is ongoing to make native binary code generation for PowerPC
based Macintoshes.
This work has caused a lot of changes to the interior of the compiler
and runtime system. These changes should, however, be transparent to
the user.

## now allowed for objects as well as for patterns
You may now use P## as an alternative to P.struc when P is an object.
Previously ## was only allowed for patterns.

$CC set in UNIX job files
The job files on UNIX platforms now set the CC environment variable to
a reasonable default value before executing the MAKE commands. Thus
$(CC) may now be used in the make files on UNIX platforms.

Check for bound SLOTs
The compiler will now only attempt to link if a PROGRAM slot has been
found in the dependency graph (this feature was introduced in v5.1 of
the compiler, but the implementation was buggy). If SLOTs of category
dopart or descriptor in the dependency graph are not bound, and linking
would otherwise have happened, the compiler now issues a warning and
does not attempt to link. This is the kind of situation that could give
an "Undefined Reference" error at link time in v5.1 (and earlier
versions) of the compiler.

Likewise, if two or more fragments try to bind the same SLOT, the
compiler will give a warning. This is the kind of situation which could
give an "Multiply Defined Symbol" error at link time in v5.1 (and
earlier versions) of the compiler.

Interfragment leave/restart
Added support for interfragment leave/restart as in

foo.bet:
ORIGIN '~beta/basiclib/v1.5/betaenv';
BODY 'foobody';
--PROGRAM:descriptor---
(# do L: <> #)

foobody.bet:
ORIGIN 'foo';
--LL:descriptor--
(# do leave L #)

This feature did not work in previous versions of the compiler.

Generalized special characters in string literals
The following special characters are now allowed in BETA string
literals (some of them, e.g. \t, has worked in previous versions, too):
\a alert (bell) character
\b backspace
\f form feed
\n newline
\r carriage return
\t horizontal tab
\v vertical tab
\\ backslash
\? question mark
\' single quote
\" double quote
\ooooctal number
The \ooo form can be shortened to \o or \oo, provided that the
character immediately following it is not a digit.

Note that the backslash character is now an escape sequence which must
itself be escaped if used literally. Thus, one must now write '\\'
instead of the old-style '\'.

Note that you may now use \' as an alternative to the old-style '' for
including literal quotes in a string. Thus, 'Tom\'s Cottage' produces
the same result as 'Tom''s Cottage'.

C14.3) New features in version 5.1 of the Compiler

The following new features have been implemented in version 5.1 of the
compiler, compared to version 5.0.

General Repetitions
Repetitions of static objects are now allowed. That is, given

A: (# ... #); V:< A;
P: (# ... #);
S: <>;

then

X: [10] @P;
XC: [11] @|P;
Y: [12] @V;
YC: [13] @|V;
Z: [14] @S;
ZC: [15] @|S;

are all allowed. The operators new and extend also applies to
repetitions of this kind, like for other repetitions.

Qualification from pattern attributes
It is now possible to qualify a reference as in the following example:

grammar: (# symbol: (# ... #); .... #);
A: ^grammar.symbol

This was previously forbidden because grammar is not an object.

THIS(P) applies to prefix
Previously THIS(P) was only known to work inside the P pattern. Now it
also works for prefixes of P, e.g.:

Q: (# x: @integer; ... #);
P: Q(# x: @integer;
do ... THIS(Q).x -> ... (* will get the x of Q *)
#)

Short-circuit Boolean Expressions
Boolean expressions are now implemented as short-circuit. That is, B2
is not evaluated if B1 is true in

B1 or B2

and B2 is not evaluated if B1 is false in

B1 and B2

Final Binding to a Virtual Pattern
Final binding of a virtual pattern to another pattern, which is virtual
itself, is now allowed. That is, given the following:

P1: (# V:< ... (* V virtual *)
W:< ... (* W virtual *)
#);

it is now allowed to do the following in a specialization of P1:

P2: P1(# W:: V (* V still virtual, but W now final bound *) #);

The implementation of this is somewhat preliminary.

Special Characters in String Literals
The compiler will no longer accept newline, carriage return or file
separator characters in string literals, not even if escaped by \. This
is to prevent errors that could occur when a string literal was not
closed, i.e. a closing quote was forgotten. This kind of error is no
longer possible. Of course, \n is still accepted in string literals.

Furthermore literal null-characters \000 in strings will now result in
a warning, since this may yield unpredictable results.

MAKE Property Behavior
When specifying a MAKE property for automatic recompilation of external
sources, the makefiles which are run are now executed relative to the
directory in which the file containing the MAKE property is placed.
This simplifies writing of makefiles a lot.

Consistent Command Line Options
The command line options that can be used when activating the compiler
have been revised and are now more consistent than previously: most
options now have an activating and a deactivating form. Furthermore
most options now have a short one-character equivalent for the
non-default form. The short options have been chosen so that the
character matches the first character in the long form as often as
possible. Short options can now be concatenated.

Please inspect chapter 8 of the Compiler manual for details, and please
note that a few options have different meanings than previously, e.g.
-c now corresponds to --noCode, where it previously corresponded to
--noLink.

C14.4) New features in version 5.0 of the Compiler

The following new features have been implemented in version 5.0 of the
compiler, compared to version 4.4.2.

Xor Primitive
An xor primitive is now supported as a basic operation on booleans.
That is

b1, b2, b3: @boolean
do (b1 xor b2)->b3

is now possible.

Simple If
Often, the following if-construct is used

b: @boolean;
do (if b//TRUE then
...
else
...
if);

The BETA compiler now supports an extension to the BETA language called
simple-if. This extension means that the case selector may be omitted
if the evaluation on the left hand side exits a boolean; it will
default to //TRUE. That is, the above may be written:

b: @boolean;
do (if b then
...
else
...
if);

Labelled imperatives
Labelled imperatives were previously defined in two forms:

L: Imp;

and

(L: Imp1; ...; :L)

The second form has now been removed from the language. Instead, the
compiler offers the form

L: (# do Imp1; ... #)

Note that this form is implemented very efficiently in the case where
there are no declarations in the object descriptor.

----------------------------------------------------------------------------

SECTION IV: The basic libraries

----------------------------------------------------------------------------

B01) How do you compare text strings in BETA?

Let's assume that we have:

t1, t2: @text;

Then:

t1[]->t2.equal

returns true if and only if t1 and t2 are equal, and

t1[]->t2.equalNCS

returns true if and only if t1 and t2 are equal up to differences in case.
----------------------------------------------------------------------------

B02) How do you read and write text in BETA?

Texts are written onto standard output by:

'hello'->screen.puttext;

which writes the string 'hello' on the screen at current cursor position.

'hello'->screen.putline;

also writes a carriage-return.

Integers are written by:

7->screen.putInt;

If you want to write onto other text variables (such as t: @text), you can
do it by:

'hello'->t.puttext;
'hello'->t.putline;
7->t.putInt;

Reading texts is equally easy:

keyboard.getline->s[];

reads a line of text from the keyboard, and assigns a reference to the read
text to the text reference s (assumed to be declared as s: ^text).

Reading from other texts (e.g. t) is done by:

t.getline->s[];

----------------------------------------------------------------------------

B03) Why does getInt followed by getLine not necessarily work as expected?

You have to be careful when scanning input entered from the keyboard. For
example, if your program has a section of the form

keyboard.getInt->...;
...
keyboard.getLine->...;

and you enter, say,

42
foo

then the string returned by keyboard.getLine will be empty because getInt
stops scanning immediately after 42 and does not consume the (non-numeric)
new-line character. [Thus, entering

42foo

works correctly.] You may insert the line

(if keyboard.peek=ascii.newline then keyboard.get if);

between the calls to getInt and getLine to get the desired effect, or even
call

keyboard.scanWhiteSpace

in which case, however, you won't be able to enter a string starting with
white-space characters, similar to the functionality of C's library function
scanf().
----------------------------------------------------------------------------

B04) What is the rationale behind the Mjolner System file directory
structures?

This entry describes the file structure of the Mjolner System. The entry is
intended as an illustration of one efficient way to structure the files of a
BETA development project. At the same time, this file structure is used all
over the existing Mjolner System to structure the various subsystems of the
Mjolner System.

Let us assume that the development project is called odin, and that it
consists of (at least) three subprojects, called brage, vidar, and vale.

We would then define the following file structure (brage/ indicates that
brage is the name of a subdirectory):

odin --+-- brage/
|
+-- vidar/
|
+-- vale/

Each of the three subprojects may exists in different versions, reflecting
the development history. These versions are kept in separate subdirectories
for each subproject. Let us illustrate with vidar (having versions 1.0, 1.1,
and 1.2):

vidar -+-- v1.0/
|
+-- v1.1/
|
+-- v1.2/

A configuration of odin now consists of the combination of the corresponding
versions of the subprojects.

Each version of each subproject has the following directory structure (here
illustrated with the 1.1 version):

The Fi.bet files contain the public interface files for the v1.1 version of
the subproject.

The private subdirectory contains the implementation fragments for the
Fi.bet interface files (see later).

The demo subdirectory contains demo programs illustrating the usage of this
subproject.

The test subdirectory contains programs for testing the functionality of
this subproject.

The (* ast files *) indicates that there will be an Fi.ast file (or an
Fi.astL for Intel-based systems) for each Fi.bet, containing the abstract
syntax tree (AST) representation of the Fi.bet.

The (* code directories *) indicates that there will be one subdirectory for
each machine type. Currently, the possible subdirectories are: sun4s, sgi,
hpux9pa, ppcmac, nti, and linux. There may be one subdirectory of each
machine type.

The substructure consisting of (* ast files *) and (* code directories *) is
shared by ALL directories, containing compiled BETA source files, and will
therefore not be mentioned further below.

The demo and test subdirectories may be further structured, possibly with a
subdirectory for each interface file Fi, but may also follow different
layouts.

The private subdirectory is divided into the following substructure:

where FiBody.bet contains the implementation fragments for the interface
files.

The FiBody.bet files may be machine-independent implementations or
machine-dependent implementations. The FiBody.bet files therefore follow the
following naming convention:

FiBody.bet
is the name of a machine-independent implementation
Fi_macBody.bet
is the name of a machine-dependent implementation(here for macintosh)

In most cases, there exists one implementation file for each interface file,
but for large (or complex) interface files, multiple implementation files
may exist (apart from the different machine dependent implementation files).

The external subdirectory contains non-BETA source files (such as C source
code), and other files which are not used directly by the Mjolner System.
The directory structure of external follows the conventions of the non-BETA
system used (e.g. the C compiler).
----------------------------------------------------------------------------

B05) What do the (* idx+ *), etc. comments mean?

At different places in the Mjolner System interface files, you may encounter
comments of the form (* idx=2 *), (* idx+ *), or (* idx- *). These are not
compiler options - the compiler totally ignores all comments. Instead, the
comments are used for formatting the interface files for the documentation.
They can be safely ignored.
----------------------------------------------------------------------------

B06) Error in v1.4/seqContainer.bet? [corrected in r4.0]

The queue pattern in v1.4/seqContainer.bet contains an error that makes the
pattern behave like a stack and not a queue. This error is removed in
v1.5/seqContainer.bet.
----------------------------------------------------------------------------

B07) Error in v1.4/regexp.bet? [corrected in r4.0]

The v1.4/regexp.bet library contains an error that manifests itself by
repetition index runtime errors when regexp is used on empty texts. This
error will be removed in v1.5/regexp.bet.
----------------------------------------------------------------------------

B08) Error in v1.4/basicsystemenv.bet? [corrected in r4.0]

The objectPort pattern in v1.4/basicsystemenv.bet contains an error that
makes it almost unusable. This error is removed in v1.5/basicsystemenv.bet.
----------------------------------------------------------------------------

B09)Why does my guienvsystemenv program stop at startup?

Possible problems in your program:

* Your program was not a specialisation of systemenv
* You did not set theWindowEnv to the guienv instance in setWindowEnv
* Your program forks in the dopart of guienv. You should fork systems in
the dopart of systemenv. This might change in a future release

Your program should look like this:

-- program: descriptor --
systemenv
(# setWindowEnv:: (# GUI[] -> theWindowEnv[] #);

GUI: @guienv
(#
do ... (* open windows here *)
#);
do ... (* fork systems here *)
#)

----------------------------------------------------------------------------

PART V: Platform Specific Issues

----------------------------------------------------------------------------

SECTION V: BETA on Macintosh

----------------------------------------------------------------------------

M01) What are the system requirements to run BETA on Macintosh?

Release 3.1: BETA for Motorola Mac

* CPU: MC68020 processor or later (Release r3.1 works on PowerPC, please
look at question M04)
* RAM: 5 Mb memory (8 or 16 Mb is recommended)
* Disk: 16 Mb of free space on harddisk
* OS: System 7.x or later (or Multifinder under System 6.x)
* The MPW environment version 3.2 or later (please see question M02 for
details).
* An FPU to be able to use reals, please see question M03 for more
details.

That is, Release 3.1 runs on machines like Classic II, SE/30, LC, LC II, LC
III, Centris, and all Macintosh II, Quadra and PowerBook models (except
PowerBook 100). Release 3.1 cannot be used at Mac Plus, SE, and Classic.
Release 3.1 works on PowerPC, please look at question M04.

Release 4.0.2 or later: BETA for PowerMac

* CPU: PowerPC 601 processor or later
* RAM: 40 Mb memory
* Disk: 60 Mb of free space on harddisk
* OS: System 7.x or later
* The MPW environment, version 3.4.1 or later (please see question M02
for details), including
o MPW Shell
o Interfaces&Libraries
o PPCLink version 1.4 or later; or MWLinkPPC from Metrowerks, see
M02
o Rez
These can be obtained from Apple from the Essentials-Tools-Objects
(ETO) volume 20 or later.
* FPU to be able to use reals (please see question M03 for more details).
However, a hardware FPU is build into most PowerPC Macintosh.

That is, Release 4.0.2 should work for alle PowerMac models. Please note
that, Release 4.0.2 or later does not work on motorola macintoshes.
----------------------------------------------------------------------------

M02) What is MPW. Where do I get it?

MPW stands for "Macintosh Programmers Workshop", which is the official
programming environment for the Macintosh, developed by Apple, Inc. The BETA
compiler runs as an MPW tool, that is, it is a command, that can be invoked
from the MPW Shell (command interpreter).

You will need MPW 3.4 or later to use BETA. In addition to the MPW Shell,
the compiler uses the MPW Link and Rez tools to build the programs.

As of october 1997, Apple has decided to make MPW freely available for
downloading. You can download it from

* ftp://dev.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/.

The current versions of the packages needed are

* MPW-3.4.2.sit.hqx.
* Interfaces_Libraries-3.0.1.sit.hqx.

Please notice, that new versions may have been available when you read this.

As an alternative to Apple's MPW, you can use the MPW supported by
Metrowerks CodeWarrior. The MWLinkPPC linker included in this commercial
package is is up to 10 times faster than PPCLink from Apple.
----------------------------------------------------------------------------

M03) Do I need a floating point unit to use BETA?

Yes, to be able to run BETA programs, that use "reals", your machine should
have a built-in FPU, *or* you can install an FPU simulator. Several
free/shareware FPU simulators are available, e.g. SoftwareFPU, which can be
fetched from most macintosh archives, or from the writer, John Neil, at
http://www.jna.com/software.html.
----------------------------------------------------------------------------

M04) Does BETA work on PowerPC machines?

As of release 4.0.2, PowerPC based macintoshes are the only macintoshes
supported.

Release 3.1 of BETA can be run on PowerMac's using the MC680x0 simulator.
That is, the applications will run with the usual slowdown for simulated
programs on PowerMac.
----------------------------------------------------------------------------

M05) Does BETA work on Motorola machines?

Release 3.1 of the Mjolner System is the last supporting Motorola
Macintoshes.

As of release 4.0.2, PowerMacintosh is the only Macintosh platform
supported.
----------------------------------------------------------------------------

M06) Known bugs, limitations and inconveniences in release 4.0.2

The current release 4.0.2 is the first for power mac, and is still
considered an "alpha release". There are a number of known bugs, limitations
and inconveniences:

1. Link time is very long for BETA programs. We have not been successful
in getting appropriate documentation from Apple to make optimal
generation of the XCOFF files.
2. Freja is not yet available for PowerMac
3. Valhalla is not yet available for PowerMac
4. bobsit will not work, because the exbobs program did not get ready for
r4.0.2
5. Problems with Sif
o Closing a workspace may make the machine crash
6. Persistence does not work
7. Check for suspend involving callbacks is not done. If you do a suspend
in a callback situation the program is likely to crash.
8. Integer division by zero will yield unpredictable results (should be
caught as an exception as on other platforms).
9. The pattern doGC in betaenv does not work on ppcmac. This is used in
implementation of

sysutils/v1.5/scanobjects

used in the demo

demo/sysutils/objinterface/scanobj

which consequently does not work
10. The PutReal pattern in ~beta/basiclib/v1.5/numberio does not work. This
is used in the demo programs in

~beta/demo/basiclib/reals/

and

~beta/demo/basiclib/random/tstgenchi.bet

which does not produce a correct output.
11. The touch and modtime.set operations on diskentry does not work
12. The iget operation on keyboard is not implemented. This is used in the
demo programs in:

~beta/demo/basiclib/iget/

which consequently does not work
13. Systemenv is not implemented
14. Process is not implemented
15. Bifrost is not implemented
16. Frigg is not available, due to some problems (Will be fixed in the next
release).
17. There is a number of problems with GuiEnv:
o There is no support for resources like icons, cursors etc.
o There are some update problems.
o The only way to make a window appear like a modal dialog is by
further binding "menubarVisible" to exit false.
o figureItems does not work yet.
18. The "Commando BETA" command in the Beta menu, does not work
19. the new timedate library does not work (linker error).

----------------------------------------------------------------------------

M07) Known bugs, limitations and inconveniences in release 4.1

M07.1) Why do I get a linker warning about errno?

There is two macintosh libraries that contains errno: StdCLib and OTXTILib -
hence the warning. OTXTILib only is used if you include the process or
distribution library. This warning can safely be ignored.

M07.2) How do I open a PersistentStore in psbrowser on the macintosh?

You have to move the psbrowser application into the directory that contains
the persistentstore you want to open before launching psbrowser. Now you can
open the persistentstore via the open command in the file menu. Be aware
that the program that generated the persistentstore must call
persistentstore_fullnamepatch included from

~beta/objectbrowser/v1.6/psbrowser/psfullnamepatch

M07.3) Why does my systemenv program not work as expected in MPW?

If you link a systemenv program as a MPW tool, the keyboard will block all
systems when you call any of the get operations: getLine, getInt etc. The
solution is to link your program as an application.
----------------------------------------------------------------------------

SECTION VI: BETA on Windows 95 and Windows NT

----------------------------------------------------------------------------

W01) What are the system requirements to run BETA on Windows 95 and Windows
NT?

* CPU: Intel 386/486/Pentium
* RAM: 16Mb (32 recommended)
* Disk: 45 Mb of free space.
* OS: Windows 95 or Windows NT 3.5.1 or later.
* Microsoft SDK, Gnu SDK or Borland SDK (only assembler, linker, make
utilities and C libraries required). Microsoft SDK recommended.

For more information, see W02.
----------------------------------------------------------------------------

W02) SDK Requirements for Windows 95 or Windows NT

In order to use the Mjolner System you need to have an assembler, a linker,
a make utility and C libraries from either Microsoft or Borland. The
Microsoft utilities are recommended.

These utilities must satisfy the following:

1. Microsoft
Assembler:
Starting from release r4.0.1, no assembler is needed any longer.

For older releases (e.g. r4.0) an assembler is needed. You can
install one of the following
+ MASM386.EXE and EDITBIN.EXE from the Microsoft WIN32SDK.
+ ML.EXE, which can be bought as a separate tool from
Microsoft. ML.EXE is also part of Microsoft Development
Network MSDN (level 2) and the Windows NT 3.5.1 DDK.
Linker:
+ LINK.EXE from e.g. Microsoft Visual C++.
Make:
+ NMAKE.EXE from e.g. Microsoft Visual C++.
If you do not plan to use the BETA MAKE facility, you can do
with a dummy NMAKE program, that simply exits 0.
C libraries:
+ from e.g. Microsoft Visual C++.
If you have installed Microsoft Visual C++ 2.0 or later for Windows 95
or Windows NT, you do not need any more software to run the Mjolner
System. If you do not have Visual C++, you will have to get a linker
and C libraries from Microsoft (http://www.microsoft.com/).
2. Gnu.
Assembler:
No assembler is needed.
Linker:
gcc and ld.
Make:
The Gnu make utility.
C libraries:
The C libraries that come with gcc for Win32.
3. Borland.
Assembler:
+ TASM32.EXE, which is sold as a separate tool from Borland.
Notice, that version 4.0 of TASM32.EXE does not work on
Windows 95. A patch is available from the Borland "Patchs
Available" WWW Page at
http://loki.borland.com/cpp/Patchs.htm. The patch is directly
available by FTP from
ftp://ftp.borland.com/pub/techinfo/techdocs/language/tools/turboasm/ta4p01.zip.
Linker:
+ TLINK32.EXE (version 1.0), which is included in the above
Assembler package from Borland, does not work under Windows

Section 5 of 6 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5 - 6

Back to category Programming - Use Smart Search

Home - Smart Search - About the project - Feedback