DOS ain't dead

David Lindauer has released the Orange C compiler and toolchain version 4.1.3 on 02 May 2010. [It] is entirely new work that is heading in the direction of a completely retargetable optimizing compiler/toolchain.

Home page & download: http://www.members.tripod.com/~ladsoft/orangec.htm

---
Forum admin

> David Lindauer has released the Orange C compiler and toolchain version
> 4.1.3 on 02 May 2010. [It] is entirely new work that is heading in the
> direction of a completely retargetable optimizing compiler/toolchain.
>
> Home page & download: http://www.members.tripod.com/~ladsoft/orangec.htm

It's basically alpha state but the (heavily-improved) successor to CC386. It does produce better (faster) code but of course still needs some work. The output is exclusively Win32/PE in HX-compatible format.

---
Know your limits.h

I played with this stuff, but am unable to link. olink.exe tells "Invalid target name":


        set ORANGEC=d:\orangec
        set PATH=d:\orangec\bin;
        olink.exe /c /T:CON test.o /otest.exe /Ld:\orangec\lib clwin.l climp.l
olink Version 4.1.3 Copyright (C) LADSoft 2006-2010
Error: Invalid target name


When I use ocl.exe instead of occ.exe - that is, the linker is called implicitely by the compiler - it works. But I need a separate link step.

Perhaps one of the smart guys here can help?

EDIT: problem solved, the olink parameter is /T:CON32, not /T:CON. This is an error in the docs.

---
MS-DOS forever!

On Oct. 3, Ladsoft released Orange C 4.1.5 for DOS/Win32.

Download: http://ladsoft.tripod.com/orangec.htm
Changes: (see below)

"The current version is about twice as fast in terms of compile time, due to various internal optimizations. There have been some bug fixes to the compiler and tool chain, and a recent addition is a new branch optimization.

In this version, I have added complete source codes for the tool chain and runtime library. The sources for the compiler have been reconfigured to compile with Borlands 5.5 C compiler as well, so that there is no need to download CC386 to compile them."

EDIT: Oops! He also has updated CC386 recently (3.7.7) at the same time, but I don't honestly know what's changed (haven't tried it yet).

> EDIT: Oops! He also has updated
> CC386 recently (3.7.7) at
> the same time, but I don't honestly know what's changed (haven't tried it yet).

COOL

Page says 3.77, "relnotes.doc" says 3.75


Release notes Version 3.75

v3.75:
        ccide:  bug fixes
        cc386:  rewrote backend
        cc386:  support binary numbers similar to hex, use '0b1111' for example which is 0xf
        cc386:  fix some problems optimizing ~0
        cc386:  fix problem with promoting unsigned char in an array index to int
                        was doing a signed promotion no matter what was specified...
        cc386:  attempts to nest one function inside another would cause the compiler to GPF
        cc386:  byte and word sized arrays inside of structures would be aligned incorrectly for win32
        cc386:  optimizing constants around %= would not work correctly
        valx:   support BCC55
        imake:  expand macros in .path.xxx: statements
        xrc:    expand line length for input lines
        xrc:    handle numeric resource types, e.g. for the xp manifest
        rtl:    if an environment var (e.g. path) is too long, toolchain and generated programs will crash.
        rtl:    miscellaneous bug fixes and enhancements
        rtl:    add i64 and binary support to sprintf & sscanf

v3.74:
        infopad: fix crash when changing tab width
        ccide:   fix memory leaks while single stepping: debugger eventually ran out of
                         resources to display things.  Especially troublesome when a lot of info
                         was shown in the watch window.
        ccide:  fix find in files to open found windows properly
        cc386:  correctly define '__DOS__' for all DOS related targets;
        cc386:  add a define '__RAW_IMAGE__' for non-dos and non-windows targets
        rtl:    fix sscanf again...  this time both the problem with returning a value
                        for '%d' on text (when it shouldn't) and the problem with requiring that
                        scanned hexadecimal numbers start with a digit are fixed


But where is the BUGzilla ???

I didn't test this version yet, following bugs IIRC were in 3.74 (tested > 2 years ago):

- INFOPAD bugs (tab issues, more ???)
- VALX MZ stub bug
- Compiler core bugs:
- - LibOGG compiles but fails self-test
- - LibTheora compiles but crashes with Page Fault (valid results with WATT-com)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> David Lindauer has released the Orange C compiler
> and toolchain version 4.1.3 on 02 May 2010

4.16 is out 2010-Oct-14.

> Most of it is written in C++. The sources for the compiler have been
> reconfigured to compile with Borlands 5.5 C compiler as well, so
> that there is no need to download CC386 to compile them

But do they compile with CC386 at all ??? The source package is messy, it contains various duplicates, intermediate ASM files, examples, tests and documentation files mixed into the sources, ... Apart from this, OCC core seems to be in C (there is CPP too in other parts). Finally, I have no big problem to download CC386 (but where to download Borlands 5.5 C ???)

> MD5 Checksums:
> 04db02282b5f0bcf1b734e77e01f4b55 *occ416e.zip (compiler executables)
> 753c24ae406d5eeb2b248a8f000b1914 *occ416s.zip (compiler and library sources)

3.3 MiB + 3.9 MiB

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > David Lindauer has released the Orange C compiler
> > and toolchain version 4.1.3 on 02 May 2010
>
> 4.16 is out 2010-Oct-14.
>

Thanks!

I always feed the newest version with the JWasm source.

However, so far the JWasm source always did manage to make Orange C crash.

---
MS-DOS forever!

http://ladsoft.tripod.com/cc386.htm http://ladsoft.tripod.com/orangec.htm

> Release notes Version 3.80
>
> v3.82
> ccide: fix problems with CCIDE being detected as a virus by AVG
> cc386: fix problems with taking the address of a static const int variable
>
> v3.81
> cc386: bug fixes to hook operator related to complex statements
>
> v3.80:
> cc386: bug fixes to new backend
>
> v3.75:
> ccide: bug fixes
> cc386: rewrote backend

Our one person's baby is not dead anymore, COOL

PS: I reported some old BUG's by mail now ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > ccide: fix problems with CCIDE being detected as a virus by AVG

We have GOT to nag these antivirus people to do a better job. Either that or disable heuristics all the time.

> We have GOT to nag these antivirus people to do a better job

NO. Don't use their fine products

http://ladsoft.tripod.com/cc386.htm

3.88 is out 2011-Jan-29 ... but broken ... fix promised

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> 3.88 is out 2011-Jan-29 ... but broken ... fix promised

3.89 is out 2011-Feb-13 ... I'll test

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

besides CC386 David Lindauer also released a new OrangeC version (4.1.16).

Size of the package increased significantly - seems mostly due to OASM.EXE, which is now 1055 kB. I wonder what cool features have been included there?

However, there's still a severe bug in the C preprocessor.

This code "should" compile without errors, but currently does not:


#include <stdio.h>

#define FAR
#define XXX(x)  T_ ## x

enum {
    XXX(NEAR),
    XXX(FAR)
} myenum;

int main(int argc, char **argv)
{
        printf("%u\n", T_NEAR );
        printf("%u\n", T_FAR );
        return( 0 );
}


---
MS-DOS forever!

> 3.89 is out 2011-Feb-13 ... I'll test

Done!

+ [0] BIG crash from 3.88 is fixed (apparently specific to DFLAT thus INSTALLER + INFOPAD)

+ [1] compiler core works (some warnings, but examples do compile and run)

+ [2] INFOPAD improvements look good

-- [3] BIG problem: CTL-BREAK causes beeper + TripleFault, in 3.89 still in, affects all binaries (at least INFOPAD and VALX, new BUG, no problem in 3.74, CTL-C still works in INFOPAD, as opposed to FP IDE)

- [4] Tiny exit problem (related to [3] ?) - INFOPAD causes a beeper "NULL POinter" (without TripleFault) but sometimes only ...

- [5] INFOPAD Out-Of-Memory-BUG (related to [3] ?) when loading a huge file (cca 2/3 of RAM), it loads, but then "Out Of Memory", and then beeper + TripleFault

http://ompldr.org/vN2c4NA/INFOPAD.ZIP (280 KiB)

Fixed 3.88 crash:


00162265061e load_seg_reg(DS, 0x0006): RPL & CPL must be <= DPL
00162265155e load_seg_reg(DS, 0x0006): RPL & CPL must be <= DPL
00162722693e read_virtual_dword_32(): segment limit violation
00162722713e read_virtual_checks(): read beyond limit
00162722733e read_virtual_checks(): read beyond limit
00162722753e read_virtual_checks(): read beyond limit
00162722773e read_virtual_checks(): read beyond limit
00162722796e read_virtual_dword_32(): segment limit violation
00162722816e read_virtual_checks(): read beyond limit
00162722836e read_virtual_checks(): read beyond limit
00162722856e read_virtual_checks(): read beyond limit
00162722876e read_virtual_checks(): read beyond limit
00162722896e read_virtual_checks(): read beyond limit
00162722916e read_virtual_checks(): read beyond limit
00162722936e read_virtual_checks(): read beyond limit
00162722959e read_virtual_dword_32(): segment limit violation
00162722979e read_virtual_checks(): read beyond limit
00162722999e read_virtual_checks(): read beyond limit
00162723019e read_virtual_checks(): read beyond limit
00162723039e read_virtual_checks(): read beyond limit
00162723059e read_virtual_checks(): read beyond limit
00162723079e read_virtual_checks(): read beyond limit
00162723099e read_virtual_checks(): read beyond limit
00162723143e check_cs(0x0018): not a valid code segment !

...

00163688374e check_cs(0x0838): not a valid code segment !
00163688374e interrupt(): segment not present
00163688374e interrupt(): segment not present
00163688374i CPU is in protected mode (active)
00163688374i CS.d_b = 16 bit
00163688374i SS.d_b = 32 bit
00163688374i EFER   = 0x00000000
00163688374i | RAX=0000000000003b8b  RBX=0000000000000000
00163688374i | RCX=0000000000000820  RDX=000000000015d89a
00163688374i | RSP=0000000000012c74  RBP=00000000001561e8
00163688374i | RSI=0000000000044aa0  RDI=0000000000000001
00163688374i |  R8=0000000000000000   R9=0000000000000000
00163688374i | R10=0000000000000000  R11=0000000000000000
00163688374i | R12=0000000000000000  R13=0000000000000000
00163688374i | R14=0000000000000000  R15=0000000000000000
00163688374i | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af PF cf
00163688374i | SEG selector     base    limit G D
00163688374i | SEG sltr(index|ti|rpl)     base    limit G D
00163688374i |  CS:0008( 0001| 0|  0) 00006c30 0000ffff 0 0
00163688374i |  DS:0000( 0000| 0|  0) 00000000 00000000 0 0
00163688374i |  SS:0820( 0104| 0|  0) 00000000 ffffffff 1 1
00163688374i |  ES:0820( 0104| 0|  0) 00000000 ffffffff 1 1
00163688374i |  FS:0818( 0103| 0|  0) 0015d99c 0000ffff 0 0
00163688374i |  GS:0000( 0000| 0|  0) 00000000 00000000 0 0
00163688374i |  MSR_FS_BASE:000000000015d99c
00163688374i |  MSR_GS_BASE:0000000000000000
00163688374i | RIP=00000000000019df (00000000000019df)
00163688374i | CR0=0x60000011 CR2=0x0000000000000000
00163688374i | CR3=0x00000000 CR4=0x00000200
00163688374i 0x00000000000019df>> retf  : 66CB
00163688374e exception(): 3rd (11) exception with no resolution, shutdown status is 00h, resetting


There are almost 10'000 protection violations before the thing finally desperates and TripleFaults ....

David Lindauber wrote:

> well it works in virtualbox...

Well, for me it (INFOPAD 3.88) "works" inside BOCHS too ... it crashes just like on real hardware, even the garbage on the screen is the same (it's just slower).

There is only one reliable emulator and that's BOCHS

(it's neither perfect nor BUG-free (I still have the mysterious XDMA-BUG, ...), and it's slow, nevertheless, it usually doesn't pretend buggy stuff to be BUG-free ...).

No BOCHS report of the CTL-BREAK-BUG.

I plan a big compiler core correctness and performance test (CC386 new vs CC386 old vs WATCOM vs DGJPP), but it might take some time.

EDIT : fixed BUG in BUG report (CTL-C vs CTL-BREAK)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

David is working on a fix.

But maybe FreeDOS also has some CTL-BREAK issues, especially with HDPMI32 involved

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> David is working on a fix

3.90 is out Feb-21 http://ladsoft.tripod.com/cc386.htm


        cc386:  fix the macro processor to handle a wider variety of standard cases
        cc386/RTL: fix behavior of exception handling, was pushing stack frames in
                        places it shouldn't
        cc386:  when avoiding generating code for branches, optimize away all the code
                        not just the branch
        CCIDE:  arrays > 32767 elements long weren't being handled right in the debugger
    CCIDE:  add toolbar button for run without debugger, update toolbar hints
        INFOPAD: don't crash when ctrl-c is signalled
        xrc:    internationalize for european languages properly in the 'version' section
        RTL:    change definition of ffs() to use bfs
        RTL/DOS: fix CTRL-C and CTRL-BREAK to not crash DOS programs


TripleFault on CTL-BREAK is gone ... crash at exit is not gone (INFOPAD only ?).




VALX version is strange - see shot.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> However, there's still a severe bug in the C preprocessor.

The preprocessor bug has been fixed in v4.1.17.

Orange C is now able to compile and link JWasm. Congrats!

However, the created jwasm binary crashes when it is to assemble a file.

AFAICS it's because the OrangeC implementation of CRT function _splitpath() - and maybe also _makepath() - don't allow NULL pointers as arguments.

MS docs:
------------------------------------------------------------------------
Each argument is stored in a buffer; the manifest constants _MAX_DRIVE, _MAX_DIR, _MAX_FNAME, and _MAX_EXT (defined in STDLIB.H) specify the maximum size necessary for each buffer. The other arguments point to buffers used to store the path elements. After a call to _splitpath is executed, these arguments contain empty strings for components not found in path. You can pass a NULL pointer to _splitpath for any component you don't need.
------------------------------------------------------------------------

---
MS-DOS forever!

> > However, there's still a severe bug in the C preprocessor
> The preprocessor bug has been fixed in v4.1.17

COOL


v3.92:
        CC386:  chained long-long assignments could leave the stack in an unstable state
                        ex a[r][s] = b[r+1][s+1] = c[r+2][s+2] = ~0
        CC386:  preprocessing stringizer sometimes got confused by quotes

v3.91:
        RTL:    fix stdout & friends when using CRTDLL.DLL
        RTL:    add MOUSEWHEEL support to win32 headers
        RTL:    fix sprintf & family, there was a space between a negative sign and its number
        XRC:    did not parse control sequences such as '\n' in string tables.  Otherwise it parsed them properly
        INFOPAD: fix crash on shutdown

v3.90:
        cc386:  fix the macro processor to handle a wider variety of standard cases
        cc386/RTL: fix behavior of exception handling, was pushing stack frames in
                        places it shouldn't
        cc386:  when avoiding generating code for branches, optimize away all the code
                        not just the branch
        INFOPAD: don't crash when ctrl-c is signalled
        xrc:    internationalize for european languages properly in the 'version' section
        RTL:    change definition of ffs() to use bfs
        RTL/DOS: fix CTRL-C and CTRL-BREAK to not crash DOS programs


I'll test.

> You can pass a NULL pointer to _splitpath for any component you don't need

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > You can pass a NULL pointer to _splitpath for any component you don't
> need
>
>

I made a few more tests in the meantime. The _splitpath/_makepath issue is rather minor, because those functions aren't "standard" (the Unix C compilers lack them completely ), and hence there's code already to emulate them.

More severe is OrangeC's handling of 64-bit integers - it seems the upper 32-bits of such integers get lost "sometimes".

EDIT:

It most likely has nothing to do with 64-bit integers, but with struct/union declarations. Test case:


#include <stdio.h>

typedef          __int64 int_64;
typedef unsigned __int64 uint_64;

typedef struct expr_list {
    union {
        struct {
            union {
                uint_64     llvalue;
                int_64      value64;
            };
            uint_64         hlvalue;
        };
    };
} expr_list;

int main(int argc, char **argv)
{
        expr_list x;

        x.llvalue = 9;
        printf( "x = %I64X\n", x.llvalue );
        x.hlvalue = 0;
        printf( "x = %I64X\n", x.llvalue );
        return 0;
}


should print:

x = 9
x = 9


but orange C 4.1.18 prints:

x = 9
x = 0


---
MS-DOS forever!

> More severe is OrangeC's handling of 64-bit integers - it seems the upper
> 32-bits of such integers get lost "sometimes".
> EDIT:
> It most likely has nothing to do with 64-bit integers, but with
> struct/union declarations. Test case:

Damn. I've been testing 64-bit in the meantime: http://jafile.com/uploads/dos386/testsily.c

Result: no misscalculations in CC386 3.92

Features of ^^^ my code:

- Compiles with CC386 or WATCOM or DGJPP (latter untested)
- Tests 64-bit (obsolete)
- 64-bit decimal output with digit bunching
- Reports non-faulty date: YYYY-MMM-DD
- Final exhaustive test for DGJPP ... anyone with DGJPP available please test

Issues:

- ui64 suffix is case sensitive (???)
- ull suffix doesn't work (fine in WATCOM)
- could not get any of the built-in output functions working (unsupported or broken or I did wrong )
- "_delay" vs "delay"
- WHEREIS.C has bad TAB and ";;" and doesn't compile with WATCOM http://jafile.com/uploads/dos386/whereis.c

Shot: http://jafile.com/uploads/dos386/testsily.png

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

9.3.2011: Orange C 4.1.19 has been released

It's the first version which is able to create a working JWasm binary.

There are still minor problems, with _makepath/_splitpath and also with 64-bit integer constants, but simple workarounds do exist to avoid them.

Of course I couldn't resist to do a first speed test - not testing compile speed, but speed of the jwasm binary which was created. The following list is a comparison of various jwasm binaries which have to assemble a very simple 400,000 lines assembly source file. All binaries were created with "Optimization enabled" (opt. for speed, if possible):


msvc:  400006 lines, 2 passes, 828 ms, 0 warnings, 0 errors
mingw: 400006 lines, 2 passes, 875 ms, 0 warnings, 0 errors
ow:    400006 lines, 2 passes, 890 ms, 0 warnings, 0 errors
pellec:400006 lines, 2 passes, 890 ms, 0 warnings, 0 errors
bcc:   400006 lines, 2 passes, 1156 ms, 0 warnings, 0 errors
occ:   400006 lines, 2 passes, 2422 ms, 0 warnings, 0 errors
cygwin:400006 lines, 2 passes, 3047 ms, 0 warnings, 0 errors

djgpp: 400006 lines, 2 passes, 80 ms, 0 warnings, 0 errors


djgpp is the only DOS binary here, and it's also put apart because the "80 ms" which it displays is cheating ( it surely isn't faster than mingw ).

---
MS-DOS forever!

... NOT documented whether DOS linking problem is fixed

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Of course I couldn't resist to do a first speed test - not testing compile
> speed, but speed of the jwasm binary which was created. The following list
> is a comparison of various jwasm binaries which have to assemble a very
> simple 400,000 lines assembly source file. All binaries were created with
> "Optimization enabled" (opt. for speed, if possible): [...]

Can you give more details about the system on which you tested?

---
Glory to God for all things

> Can you give more details about the system on which you tested?

A P4 system, 2.8 GHz, 1.5 GB RAM, WinXP SP2.

---
MS-DOS forever!

> ... NOT documented whether DOS linking problem is fixed

Not sure, but admittedly OrangeC still "seems" to not link correctly in FreeDOS (for me). Maybe I did something wrong (HX %PATH% conflict?), or maybe it's a FreeCOM bug, or maybe it works fine in MS-DOS, dunno.

> > ... NOT documented whether DOS linking problem is fixed
>
> Not sure, but admittedly OrangeC still "seems" to not link correctly in
> FreeDOS (for me). Maybe I did something wrong (HX %PATH% conflict?), or
> maybe it's a FreeCOM bug, or maybe it works fine in MS-DOS, dunno.

CC386 still has the fscanf bug I already reported (2^30-1 maximum integer). He must be too busy these days. :-/

> CC386 still has the fscanf bug I already reported (2^30-1 maximum integer).
> He must be too busy these days. :-/

Fixed in 4.02 (and of course 4.03 was just released yesterday, doh!).

Linking BUG fixed in 4.00
Bugged 3.96 kicked from ibiblio
Compiler seems to work
INFOPAD updated too
Some garbage files added "func.c an386.c"

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > ... NOT documented whether DOS linking problem is fixed
>
> Not sure, but admittedly OrangeC still "seems" to not link correctly in
> FreeDOS (for me). Maybe I did something wrong (HX %PATH% conflict?), or
> maybe it's a FreeCOM bug, or maybe it works fine in MS-DOS, dunno.

(BTW, linking seems fixed by now in OCC.)

CC386 4.05 (Dec. 8, 2011) -- http://ladsoft.tripod.com/cc386.htm
OrangeC 4.1.24 (Dec. 1, 2011) -- http://ladsoft.tripod.com/orangec.htm

> CC386 4.05 (Dec. 8, 2011) -- http://ladsoft.tripod.com/cc386.htm

What's new: fixed one BUG

Seems to work (4.04), still warnings in DOS examples

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

CC386 4.06 2012-Jan-02 http://ladsoft.tripod.com/cc386.htm

> What's new: fixed one BUG

OCC 4.1.25 2012-Jan-14 http://ladsoft.tripod.com/orangec.htm

> What's new: ???

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> OCC 4.1.25 2012-Jan-14 http://ladsoft.tripod.com/orangec.htm

OLINK.EXE bug is back (only under FreeCOM? seems to work fine in 4DOS). Also seems he omitted to include DKRNL32.DLL.

This makes me wish he would add a -save-temps or -v or similar to show explicitly what subprocesses it tries to run.

> OLINK.EXE bug is back (only under FreeCOM?

Please try EDR-DOS.

CC386 4.07 2012-Jan-19 http://ladsoft.tripod.com/cc386.htm

What's new: ???

OCC 4.1.25 2012-Jan-14 http://ladsoft.tripod.com/orangec.htm not updated

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> CC386 4.07 2012-Jan-19 http://ladsoft.tripod.com/cc386.htm

CC386 4.09 2012-Nov-23

What's new: ??? (1 bug-fix in 4.08, no notice about 4.09)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > CC386 4.09 2012-Nov-23 http://ladsoft.tripod.com/cc386.htm

I haven't tried this and don't know any more than you here, but I did mirror it to iBiblio for us.

I haven't ever heavily tested CC386, mostly because I'm still fairly green on pure ANSI C (and most third-party code is for GCC/Linux/POSIX these days). It's very nice, though, but if you want a laugh, try building Lua with it. (Save your work first!) IIRC, it didn't quite "like" that.

CC386 4.10 2013-Jan-19 http://ladsoft.tripod.com/cc386.htm

What's new:

(nothing ... no need to mirror)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***