DOS ain't dead - MPXplay under CWSDPMI

Laaca

Czech republic,
16.10.2010, 17:25

MPXplay under CWSDPMI (Users)

Does anybody know why MPXplay (at least the DOS4G version) always crashes with loaded CWSDPMI? (via cwsdpmi -p)
It writes a nice crash report but doesn't work. Doesn't matter if I run cwsdpmi r5 or cwsdpmi r7.
The strange point is that under HDPMI32 it works without problem.

It is problem on MPXplay side or on CWSDPMI side?

---
DOS-u-akbar!

ecm

Düsseldorf, Germany,
16.10.2010, 18:40

@ Laaca

MPXplay under CWSDPMI

Post reply

> It is problem on MPXplay side or on CWSDPMI side?

I would guess it is a CWSDPMI bug. Remember, it isn't intended for real work.

---
l

Rugxulo

Usono,
17.10.2010, 01:39

@ ecm

MPXplay under CWSDPMI

Post reply

> > It is problem on MPXplay side or on CWSDPMI side?
>
> I would guess it is a CWSDPMI bug. Remember, it isn't intended for real
> work.

CWSDPMI r1 shipped with the original Quake (commercial) in 1996, 1.06 (I think 1.09 was latest in GPL srcs circa 1999). It's also included in some ROMs. And it was used by Norton's Ghost (well, "old" version nowadays). So it's for real work. (Okay, so Quake used DJGPP 2.00 beta3 and that had some *nix sbrk default memory management which had issues with later versions due to changes. But that wasn't his fault, id just decided to abandon DOS as quickly as possible, esp. for NT, which didn't fully support DPMI correctly and hence wouldn't run DOS Quake.) It's the standard host used for DJGPPv2 apps (in stub), at least when not on Windows or OS/2.

The problem is, as Japheth says, probably due to undocumented additions. DOS/4G is more than just a plain "standard" DPMI host. CWSDPMI is "only" a 32-bit DPMI host without any undocumented / non-standard "extended" int 21h APIs, and it doesn't support 16-bit clients at all. According to CWS, various Watcom games (Doom, etc.) needed various unofficial hacks and had bugs and didn't consistently do the right thing. By the time he was writing CWSDPMI (in lieu of unfinished / abandoned MWDPMI or GO32 for v1) for DJGPP v2, nobody ever needed or wanted 16-bit DPMI apps, so nobody complained, and he dropped the issue.

The real question is why you would want to use CWSDPMI here (virtual memory?). I'm not saying you're wrong to try, but if it doesn't work, it doesn't work. :-|

ecm

Düsseldorf, Germany,
17.10.2010, 01:56

@ Rugxulo

MPXplay under CWSDPMI

Post reply

> CWSDPMI r1 shipped with the original Quake (commercial) in 1996, 1.06 (I
> think 1.09 was latest in GPL srcs circa 1999). It's also included in some
> ROMs. And it was used by Norton's Ghost (well, "old" version nowadays). So
> it's for real work. (Okay, so Quake used DJGPP 2.00 beta3 and that had some
> *nix sbrk default memory management which had issues with later versions
> due to changes. But that wasn't his fault, id just decided to abandon DOS
> as quickly as possible, esp. for NT, which didn't fully support DPMI
> correctly and hence wouldn't run DOS Quake.) It's the standard host used
> for DJGPPv2 apps (in stub), at least when not on Windows or OS/2.

From a mail I got from Charles last month, in reply to some bug reports and feature requests (related to DOS TSR stuff):

CWS> First, it's quite interesting to get an email about CWSDPMI. In the
CWS> last 10 years, I have only gotten about a dozen emails, almost all
CWS> more than 7 years ago. At the time it was included as part of
CWS> Symantec Ghost image. That was the last major usage I'm
CWS> aware of.

CWS> I have one outstanding
CWS> request for some VLM window mapping software (>4GB
CWS> testing), but other than that I was convinced that DOS (and
CWS> the need for CWSDPMI) was completely dead.

CWS> I'm well aware of the hackiness of CWSDPMI - it was
CWS> supposed to be an interim solution until MWDPMI was
CWS> completed. But it worked well enough such that I really
CWS> had lost interest in DPMI by 1997. Every few years someone
CWS> would convince me to fix a problem over a vacation.

CM> The code to uninstall CWSDPMI will not check whether it can safely do so.
CM> Instead, it'll always reset the interrupt 2Fh handler to the saved value.

CWS> Lots of other similar issues. It does the same when restoring hardware
CWS> interrupt hooks, and reprogramming the PIC. It grabs all memory and
CWS> doesn't hook Int15 to tell.

CM> The code to uninstall CWSDPMI will, within a short window, execute
CM> code in unallocated DOS memory.

CWS> This was purely for size and simplicity reasons. The 3 lines to do it
CWS> were trivial to write and worked without problems in testing, so since
CWS> it never broke it never was fixed.

CWS> Thanks for the comments. If you review some of the hairy internal code
CWS> around nested interrupts, stack switching, and other things you will
CWS> find much more serious potential problems. The raw mode switching has
CWS> some big holes in the implementation.
CWS>
CWS> If you or someone else is actually still using CWSDPMI for real work,
CWS> let me know !

So please send him a mail if you really want to use CWSDPMI, because I'm not using it. (I did not yet reply to him either. Maybe I'll prepare some patches for a CWSDPMI r8 first, but then again, who uses CWSDPMI?)

---
l

Rugxulo

Usono,
17.10.2010, 06:02

@ ecm

MPXplay under CWSDPMI

Post reply

(long reply follows, sorry!!)

> From a mail I got from Charles last month, in reply to some bug reports and
> feature requests (related to DOS TSR stuff):
>
> CWS> First, it's quite interesting to get an email about CWSDPMI. In the
> CWS> last 10 years, I have only gotten about a dozen emails, almost all
> CWS> more than 7 years ago.

While it's true that he never got many e-mails about it, part of that is a bit of an oversimplification. It's been pretty darn "stable" since 2000 (original r5). Everything before that had bugs, even if plenty of people still shipped r3 or r4 (and I had to track down and nag a few).

Unofficial r5 2002 (also on DJ's server) had three bug fixes, and there were other minor issues, but it was mostly moot because it worked fine. There wasn't much other work on alternative DPMI servers, esp. since r5 added CWSDSTUB support. What others still exist (EDIT: for DJGPP) are mostly leftover from years past and fairly abandoned (e.g. D3X, whose original Geocities site is long dead, and which I don't think anybody even mirrors besides me, sheesh, but DJ didn't like the non-commercial license, whereas I liked that it could totally build in NASM+GCC and also supports OpenWatcom).

For some reason, FreeDOS shipped an (old, buggy?) version of HDPMI32 renamed as CWSDPMI, which didn't help things.

CWS was (and still is, barely) a big fan of Win2k, but that had various bugs (as did original NT 4) in DPMI. Nevertheless, until Vista, NTVDM "mostly" worked with some workarounds (for leaking selectors) in DJGPP 2.03p2 (2001) and unfinished 2.04 beta (2003). So XP was a good platform for DJGPP, which is mostly frozen but still gets updated ports of major GNU tools (GCC, BinUtils, Emacs). So yeah, the need for CWSDPMI wasn't as crucial because Windows (multitasking, networking) "mostly" worked. But with sloppy Vista and AMD64, the need has become more apparent again. (Oh, and I nagged him to add SSE support for my lousy paq8o8 tweaked port.)

> At the time it was included as part of
> CWS> Symantec Ghost image. That was the last major usage I'm
> CWS> aware of.

Cygnus also (allegedly) used to use DJGPP a lot, and they are the reasons for v2 being less reliant on Turbo C (for the stub). Of course, I always wondered why they never bothered nagging about CWSDPMI (Borland C), but whatever. Remember that DJGPP has been around since 1989, and a decent Win32 port of GCC didn't appear until at least 1998 (Cygwin), maybe later, and MinGW forked from Cygwin initially.

A lot of people wanted to use DJGPP to write DOS graphics games, but with Allegro dropping support, XP being flaky, Vista being broken, and AMD64 being completely incompatible, that doesn't help either. (Plus many migrated exclusively to Linux and refused to port their apps or accept patches, which I think is a bit snobbish, but anyways ....)

> CWS> I have one outstanding
> CWS> request for some VLM window mapping software (>4GB
> CWS> testing), but other than that I was convinced that DOS (and
> CWS> the need for CWSDPMI) was completely dead.

Obviously that can't be true or he'd have never updated r5 in 2008 nor r7 in early 2010. Old "stable" r5 had issues with > 512 MB machines. Initially, they thought 128 or 256 MB would be "plenty for everyone" (famous last words), but when it doesn't load page tables high (like HDPMI32 or MWDPMI), that has issues and needs swapping somewhere (even to RAM drive). r7 uses 4 MB pages, if available, to avoid this. (This really only became apparently when machines started having 1 GB or more of RAM, circa 2007, due to Vista's heavily-increased footprint.)

He knows DOS isn't "dead" because one bugfix was for FreeDOS EMM386. FD 1.0 was released as "recently" as 2006, which took many volunteers a long time to build. It wasn't developed overnight or in a closet somewhere. (DOSEMU has its own DPMI host but does rely on a real DOS, like FreeDOS, to work, unlike DOSBox which only needs CWSDPMI or similar, by default.)

> CWS> I'm well aware of the hackiness of CWSDPMI - it was
> CWS> supposed to be an interim solution until MWDPMI was
> CWS> completed. But it worked well enough such that I really
> CWS> had lost interest in DPMI by 1997. Every few years someone
> CWS> would convince me to fix a problem over a vacation.

r5 fixed some stuff and added CWSDSTUB, "mostly" obsoleting the need for PMODE/DJ. It's just that many DJGPP ports started requiring LFNs more and more, which was much more convenient to build on XP or similar. (This was before MS totally gave up the ghost on DOS NTVDM support. Ever since 2001 with XP, Windows has been much much weaker in DOS and DPMI support. Part of the decline is due to that alone, which means no more native MS-DOS 7, only emulated NTVDM, a hacked MS-DOS 5 with bugs.)

Also, I don't think MW (Morten Welinder) has been involved in DJGPP in well over 15 years. So yeah, MWDPMI is still in CVS, but it's more than just a little painful to build it (old tools needed, esp. due to inline asm syntax changes, stupid GNU). And it lacks support for exceptions (or whatever) anyways, I think Eli Z. said once. So I'm not sure it was ever even considered stable or usable. If so, I'd be highly surprised. (I did build it once or twice, it sorta worked, but CWSDPMI is better. Heck, I even barely converted CWSDPMI r5 to asm to avoid a C compiler for build simplicity, but I never bothered finishing, esp. since I didn't like nor understand all the TASM constructs.)

> CWS> This was purely for size and simplicity reasons. The 3 lines to do
> it
> CWS> were trivial to write and worked without problems in testing, so
> since
> CWS> it never broke it never was fixed.

Don't forget that CWS is an extremely busy person (engineer for big oil). I'm just saying, he doesn't have tons of free time to update it every year or so because of his constant overtime and family, etc. I'm just saying, we're extremely lucky to have him contribute. I'm not a very good x86 programmer, so I don't understand pmode very well. Maybe it does have some more latent bugs, but overall it seems to work just fine.

> CWS> If you or someone else is actually still using CWSDPMI for real work,
> CWS> let me know !

"Real work" probably means commercial business. Last I heard, he still had various boxes running Win2k that he used DJGPP on (Bash, etc). He liked the lower footprint of 2K compared to XP. I know he wasn't happy about upgrading his company to Vista a year or so back (and I can't say I blame him). MS VS2010 doesn't even support Win2k or XP less than SP2 anymore without unofficial hacks. (I can't remember, was it July of this year when MS dropped 2K? Was that "extended" support? Most projects haven't totally dropped it, but that's been coming for a while, sadly. Luckily, XP users are more stubborn, barely. And no, I don't know of any reason why Win7 is truly any better, I don't understand the hype behind that.)

> So please send him a mail if you really want to use CWSDPMI, because I'm
> not using it. (I did not yet reply to him either. Maybe I'll prepare some
> patches for a CWSDPMI r8 first, but then again, who uses CWSDPMI?)

Who uses CWSDPMI? RAINE, VIM, FPC, UPX, 4tH, etc. Obviously DJGPP still uses it if available (stubedit -v blah.exe). Oh, and FBC, GPC, etc compilers and their outputs. Pretty much anybody using "GO32v2" or DJGPP or DPMI under DOS (if not already using HDPMI32 or one of the OpenWatcom extenders). Remember, OpenWatcom 1.0 was "only" released in 2003, and Debian hates their license, so it wasn't immediately available as early as DJGPP was, nor did it include modern updated Causeway (OW 1.8?) or DOS/32A (still doesn't, 7.2 is old). It can't be any worse than DOS/4GW or PMODE/W, which are either barely sold or totally abandoned, respectively (EDIT: and closed src).

DOS386

23.10.2010, 09:08

@ Rugxulo

MPXplay under CWSDPMI

Post reply

> MPXPLAY DOS4G crashes with CPWSPMI

I use neither DOS4G (is it freeware at all???) nor CWSDPMI (why? Blocek memory leak bug?), so ...

BTW, the DOS/32A version runs under HDPMI32 although it's a known fact that DOS/32A doesn't love external DOS based DPMI hosts too much either.

> CWS was (and still is, barely) a big fan of Win2k, but that had various
> bugs (as did original NT 4) in DPMI.

Good :-)

> A lot of people wanted to use DJGPP to write DOS graphics games, but with
> Allegro dropping support, XP being flaky, Vista being broken

How are XP and Wista related to DOS development (or lack of) ?

> and AMD64 being completely incompatible

Did they drop real mode ??? :confused:

> You could try D3X, but no guarantees it works better

D3X is cool :-) but:

- not residentable
- spawn-BUG
- ARF-BUG
- maybe other bugs

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

Rugxulo

Usono,
23.10.2010, 10:43

@ DOS386

MPXplay under CWSDPMI

Post reply

> > MPXPLAY DOS4G crashes with CPWSPMI
>
> I use neither DOS4G (is it freeware at all???) nor CWSDPMI (why? Blocek
> memory leak bug?), so ...

http://www.tenberry.com/dos4g/watcom/4gwtable.html

> BTW, the DOS/32A version runs under HDPMI32 although it's a known fact that
> DOS/32A doesn't love external DOS based DPMI hosts too much either.

I wonder which ones caused him to implement it that way.

> > CWS was (and still is, barely) a big fan of Win2k, but that had
> various
> > bugs (as did original NT 4) in DPMI.
>
> Good :-)

Good that it had bugs? It is a standard, just MS failed to keep up (short attention span, I guess, always running after the latest thing). It just boggles my mind that they would let that slide, esp. if it's for some insane reason like market share / control or something dumb like that (which I doubt but ya never know).

> > A lot of people wanted to use DJGPP to write DOS graphics games,
> but with
> > Allegro dropping support, XP being flaky, Vista being broken
>
> How are XP and Wista related to DOS development (or lack of) ?

They can run V86 mode (except under 64-bit versions) and have their own NTVDM / modified DOS for compatibility and full speed (citation needed). When it works, it works well. When it doesn't ....

> > and AMD64 being completely incompatible
>
> Did they drop real mode ??? :confused:

No, but nobody wants to constantly reboot, esp. because raw FreeDOS doesn't have all the driver support that modern OSes have. Emulators are nice but slow. That's why hardware support (V86 mode, VT-X) is extra nice, but for some reason that is often ignored or marginalized.

Also, face it, software isn't getting smaller, it's getting bloatier. Eventually we'll need 300 GB just to say "Hello, world!". And then FreeDOS (unless rewritten) will truly be dead because the hardware people will of course (in their infinite wisdom) stop putting legacy mode support in their fabs (just to save a few pennies).

> > You could try D3X, but no guarantees it works better
>
> D3X is cool :-) but:
>
> - not residentable
> - spawn-BUG
> - ARF-BUG
> - maybe other bugs

Everything has bugs. D3X isn't perfect. Probably the best thing about it is that it can be rebuilt in NASM. Okay, well, it supports raw asm, Watcom, or DJGPP. So that's good too. And it's small. Too bad nobody ever converted DOS/32A, CWSDPMI, etc. (MWDPMI doesn't count, it's old, abandoned, half-finished IMHO.)

cm, since you love (N)ASM so much, maybe I should send you my (unpolished but working) "port" of CWSDPMI r5 2008 to 100% assembly (still uses proprietary assemblers, sadly). I'm not saying you have to do anything with it, but I figure I should at least send it to somebody with a vague interest in it. (Already sent it to Charles a few months back, heh, he obviously couldn't care less. It's all his fault, heh, damn TASM fiend. I just honestly don't understand some of that TASM HLL crap, I'm just too dumb.)

DOS386

23.10.2010, 10:56

@ Rugxulo

MPXplay under CWSDPMI

Post reply

> > > and AMD64 being completely incompatible
> > Did they drop real mode ??? :confused:
> No, but nobody wants to constantly reboot

Maybe, but:

1. if things worked in DOS you would not have to reboot
2. Windaube can boot fast if you remove some of the useless crap (and Firefox still works)

> esp. because raw FreeDOS doesn't have all the driver support that modern OSes have

You are not pressured to support silly stuff like bidirectional communication with 3 monitors, BlueJunk or whatever just because "modern OSes" do ;-)

> Also, face it, software isn't getting smaller, it's getting bloatier.
> Eventually we'll need 300 GB just to say "Hello, world!". And then FreeDOS

FreeDOS still can run 8 MiB HELLO.EXE from Quack-64 :-)

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

Rugxulo Usono, 24.10.2010, 01:14 @ DOS386	MPXplay under CWSDPMI Post reply
	> FreeDOS still can run 8 MiB HELLO.EXE from Quack-64 Thanks to the enormous efforts and generosity of Japheth. Long live the Japheth! (I need to complain less and be more grateful. There has been some really wonderful DOS software written lately. If only I knew the best way to help further ... any suggestions??)

ecm

Düsseldorf, Germany,
23.10.2010, 18:02

@ Rugxulo

CWSDPMI assembler port

Post reply

> cm, since you love (N)ASM so much, maybe I should send you my
> (unpolished but working) "port" of CWSDPMI r5 2008 to 100% assembly (still
> uses proprietary assemblers, sadly).

Which assemblers? I mean, it's probably MASM/JWASM or TASM ideal mode, but I'm not in the mood for guessing. (And it could be A386 or something.)

> I'm not saying you have to do anything with it,

As user, HDPMI just seems the better choice right now. As developer, I'm not interested in DPMI hosts currently. Besides, CWSDPMI probably has a long way to go.

> but I figure I should at least send it to somebody with a
> vague interest in it.

You could ask Robert to upload it on our site. Since no one seems interested, no promises we'll host it. Maybe creating a SourceForge project for it would be the better choice.

> I just honestly don't understand some of that TASM HLL crap, I'm just too
> dumb.

I don't instantly understand Japheth's more complicated MASM macros and such either. It's just my lack of interest. If in doubt, compare it to the output.

---
l

Rugxulo

Usono,
24.10.2010, 01:30

@ ecm

CWSDPMI assembler port

Post reply

> Which assemblers? I mean, it's probably MASM/JWASM or TASM ideal mode, but
> I'm not in the mood for guessing. (And it could be A386 or something.)

TASM and JWASM and TLINK but one file (for some odd reason, ironically) didn't like TASM32 5.3 at the time, so I just used LZASM. All of these tools are (well, were) freeware. Sadly, Embarcadero doesn't distribute Turbo C++ 2006 anymore, which is where I got TASM32. Yet another reason to leave that monster (TASM syntax) behind. (WASM and YASM both somewhat support TASM syntax, and NOMYSO was updated less than a year ago. So it's not that hopeless a cause.)

It's not that HLL-ish stuff in ASM is so bad, but man it's a pain to translate to other assemblers! I mean, x86 asm is non-portable enough as it is, I don't need the extra syntax incompatibilities choking me also! (In contrast, the incompatible MOSS "extender" claimed to be written almost entirely in C. But that is old old old and I wasn't GNU-savvy enough to understand the extremely outdated build process, old AutoConf, etc.)

> > I'm not saying you have to do anything with it,
>
> As user, HDPMI just seems the better choice right now. As developer, I'm
> not interested in DPMI hosts currently. Besides, CWSDPMI probably has a
> long way to go.

Heh. Okay, HDPMI32 is better (unless you need swapping), admittedly, but CWSDPMI is still very very good, IMHO. No, it won't work with int 21h extensions nor 16-bit clients, but that's fairly rare anyways (I don't have BP7). Both are truly awesome for what they do. Now if only I had to courage to even try to reassemble HDPMI32, heh.

> > but I figure I should at least send it to somebody with a
> > vague interest in it.
>
> You could ask Robert to upload it on our site. Since no one seems
> interested, no promises we'll host it. Maybe creating a SourceForge project
> for it would be the better choice.

I mentioned it (along with various other things) on comp.os.msdos.djgpp to zero interest. Bah, so frustrating that a project is so dead / frozen that nobody can do anything. It's a damn miracle we still get ports of anything from them. Honestly, I think DJ just works too hard or is too tired, I dunno. Or maybe he's really given up on DOS. (I know Windows is a lost cause.) He did say 2.04 will be the last, but it doesn't look like even that will be finalized by him. CWS showed interest, so hopefully he'll pick up things eventually (though I can't help but be somewhat skeptical here), he works too hard (that's what he gets for being too smart, heh).

> > I just honestly don't understand some of that TASM HLL crap, I'm just
> too
> > dumb.
>
> I don't instantly understand Japheth's more complicated MASM macros and
> such either. It's just my lack of interest. If in doubt, compare it to the
> output.

Easier said than done, esp. with something so sensitive as a DPMI host! Heck, I weakly tried to "port" FreeMacs (also uses TASM) and it didn't work correctly, so I gave up (probably too impatient, alas). Some things are easier than others. :-/

Laaca

Czech republic,
17.10.2010, 10:08

@ Rugxulo

MPXplay under CWSDPMI

Post reply

>The real question is why you would want to use CWSDPMI here (virtual memory?).
>I'm not saying you're wrong to try, but if it doesn't work, it doesn't work.

Well. I think you agree that crashes are generaly not good. :-D
MPXplay should at least write something like "CWSDPMI detected, crashes reported, continue? (Y/N)"

I normaly don't load CWSDPMI permanently but when is it loaded it somewhat increases stability of some software (ELINKS, GTA I in HiColor mode, some others). And generaly - when I got crash with some DOS4GW or DOS32A program I always try to run it also under CWSDPMI.

I have never discovered any problem with it, MPXplay is the only one.

If CWS is worried that CWSDPMI is not used he is wrong. What about DJGPP, Freepascal, Freebasic, Euphoria and all programs generated by them?

---
DOS-u-akbar!

Rugxulo

Usono,
17.10.2010, 15:46

@ Laaca

MPXplay under CWSDPMI

Post reply

> Well. I think you agree that crashes are generaly not good. :-D
> MPXplay should at least write something like "CWSDPMI detected, crashes
> reported, continue? (Y/N)"

BTW, detecting CWSDPMI at runtime is very very easy.

> I normaly don't load CWSDPMI permanently but when is it loaded it somewhat
> increases stability of some software (ELINKS, GTA I in HiColor mode, some
> others). And generaly - when I got crash with some DOS4GW or DOS32A program
> I always try to run it also under CWSDPMI.

You could try D3X, but no guarantees it works better. At least, I know shelling out from TDE (which used CWSDPMI) won't crash, IIRC, unlike WDOSX stuff.

> If CWS is worried that CWSDPMI is not used he is wrong. What about DJGPP,
> Freepascal, Freebasic, Euphoria and all programs generated by them?

He's not naive, he knows it's still used fairly widely, I think he's just being realistic that DOS isn't top tier and is mostly ignored these days.

Laaca

Czech republic,
17.10.2010, 17:33

@ Rugxulo

MPXplay under CWSDPMI

Post reply

> > Well. I think you agree that crashes are generaly not good. :-D
> > MPXplay should at least write something like "CWSDPMI detected, crashes
> > reported, continue? (Y/N)"

However, much better would be to coexist with CWSDPMI, of course.
What makes the problem - functions from Openwatcom or own assembler code?

---
DOS-u-akbar!

Rugxulo

Usono,
17.10.2010, 23:23

@ Laaca

Post reply

> I guess that MPXplay checks on startup if a DPMI host is installed and,
> when one is found, uses it. It probably assumes that the host which it has
> found is a "full" host and makes no further checks. If so, then it's a bug
> of MPXplay.

Hm, and even if MPXplay will recognize the category of DPMI host, what it can do with it? Could it load own extender over CWSDPMI? If not then it just can display error message with better meaning...

---
DOS gives me freedom to unlimited HW access.

Mpxplay

28.10.2010, 08:48

@ Japheth

MPXplay under CWSDPMI

Post reply

>
> > It is problem on MPXplay side or on CWSDPMI side?
>
> I guess that MPXplay checks on startup if a DPMI host is installed and,
> when one is found, uses it. It probably assumes that the host which it has
> found is a "full" host and makes no further checks. If so, then it's a bug
> of MPXplay.
>
> However, the API how to check whether the DPMI host is "plain" or "full" is
> undocumented :-D - so it's a bit questionable to blame the author of
> MPXplay.

I don't do anything with DPMI in my own source. I already have the 32-bit dpmi environment at (before) the first line of my code.
I haven't checked, but I think so there's no such stuff in the linked stub neither (that calls the dos4g.exe). Probably the DPMI host checking is in the dos4g.exe (and it's not opensource), so I cannot modify it (but I don't want it neither)...

btw. Laaca. I don't understand why did you load the cwsdpmi like a "host" (tsr). It have to work similar like the using of dos4g (the program should load the cwsdpmi if it needs, you don't have to pre-load it)...

btw2. (the answer to your original question) probably the DLL handling part of Mpxplay crashes, because there are no such functions (API) in the CWSDPMI (these functions are also missing from DOS4GW.EXE, only DOS4G.EXE have them)
Maybe I can add something api check to my code with a nice exit-error message, but I cannot load a new/other dpmi host.

Rugxulo

Usono,
28.10.2010, 11:41
(edited by Rugxulo, 28.10.2010, 11:57)

@ Mpxplay

MPXplay under CWSDPMI

Post reply

N.B. I'm a horrible programmer. You are 10x the coder I will ever be. So please don't take any of this as condescending, it's not. I'm just clarifying what I (barely) know. You probably knew all of this already anyways. (Corrections and clarifications welcome.)

> I don't do anything with DPMI in my own source. I already have the 32-bit
> dpmi environment at (before) the first line of my code.

Who says it's using DPMI? It could be using raw, XMS, EMS/VCPI instead. DPMI is just an API, it's not the same as 32-bit pmode (esp. since DPMI can also be 16-bit, e.g. 286). VCPI existed for a while before DPMI (Win 3.0). Old "WIN.COM /S" (standard mode) was the only way to get VCPI in Windows, and that's long since been abandoned.

> I haven't checked, but I think so there's no such stuff in the linked stub
> neither (that calls the dos4g.exe). Probably the DPMI host checking is in
> the dos4g.exe (and it's not opensource), so I cannot modify it (but I don't
> want it neither)...

I haven't checked your sources lately, do you use much inline asm? But anyways, IIRC, DOS/4G and DOS/4GW weren't meant for DJGPP, nor was CWSDPMI meant for Watcom. CWSDPMI is not an "extender" at all, it only provides the DPMI API (plus low-level support) and even then only for 32-bit stuff. OpenWatcom/DOS (mostly) only supports LE while DJGPP only (properly) supports COFF. You can't use the DJGPP stub with OpenWatcom.

> btw. Laaca. I don't understand why did you load the cwsdpmi like a "host"
> (tsr). It have to work similar like the using of dos4g (the program should
> load the cwsdpmi if it needs, you don't have to pre-load it)...

Right, I can't see why he would want to use it either unless he wanted swapping for some reason.

>> And generaly - when I got crash with some DOS4GW or DOS32A program I
>> always try to run it also under CWSDPMI.

Most apps are only tested with one DPMI host or one extender. It's very rare that switching helps. I know OpenWatcom brags about their drop-in replacements, but none of them support the full DPMI 0.9 standard, even (last I checked), only a subset.

> btw2. (the answer to your original question) probably the DLL handling part
> of Mpxplay crashes, because there are no such functions (API) in the
> CWSDPMI (these functions are also missing from DOS4GW.EXE, only DOS4G.EXE
> have them)

Right, DLLs are not part of the standard. And all these extended 32-bit variants of the 16-bit DOS API are non-standard also. DJGPP doesn't use any of that, and CWSDPMI primarily exists only for DJGPP (though well-behaving apps from others could work too, in theory, and I'm not implying Mpxplay isn't well-behaving here). DJGPP does "have hooks" (as Rod P. often says) for full DPMI 1.0, but most of that is disabled because Windows never supported more than 0.9 (though OS/2 allegedly came closer with 0.95). DJ said that 0.9 was the older, 286 version. The unpopular 1.0 was where some additional 386-only features came into play.

> Maybe I can add something api check to my code with a nice exit-error
> message, but I cannot load a new/other dpmi host.

"Get DPMI Capabilities -- DPMI 1.0"

http://www.delorie.com/djgpp/doc/dpmi/api/310401.html

IIRC, only CWSDPMI r5 and up support this (which should be plenty of leeway, IMHO). r6 was never finalized and was buggy, so r7 is the true successor to that. r6 calls itself "5.00" also (bug). r7 does correctly identify itself as 7.00. Note that CWSDPMI is not a full 1.0 implementation. I don't know if anybody outside of DPMIONE (or its cousin 386MAX?) ever did that, not even HDPMI32 (yet? right??). Still, CWSDPMI does support a few 1.0 calls.

.get_dpmi: mov ax,401h ; get DPMI capabilities mov cx,128 mov edi,dpmi_buf stc int 31h jc .fiddle .dosemu: cmp dword [dpmi_buf+2],'DOSE' jnz .cwsdpmi cmp dword [dpmi_buf+2+2],'SEMU' jz .no_fiddle .cwsdpmi: cmp dword [dpmi_buf+2],'CWSD' jnz .fiddle cmp dword [dpmi_buf+2+3],'DPMI' jnz .fiddle .no_fiddle: xor eax,eax inc al jmp .ret .fiddle: xor eax,eax .ret: pop edi ret

EDIT: Here's a DJGPP version I had lying around:

#include <stdio.h> #include <dpmi.h> int main() { int flags; char vendor[129]; if (__dpmi_get_capabilities(&flags,vendor) == 0) printf("\nVendor = %s, version = %d.%d\n",&vendor[2],vendor[0],vendor[1]); else printf("\nNo vendor id found.\n"); return 0; }

Mpxplay

28.10.2010, 15:01

@ Rugxulo

Post reply

> > Hm, I just tried to run DOOM - sound on ( SB emulation ) - with CWSDPMI
> and
> > it reboots quickly. Without sound it runs, but I guess you also started
> > mpxplay WITH sound emulation loaded?
>
> I tried cwsdpmi r7 -p under MSDOS 6.22 and it does evil things to dos4gw
> progs.
>
> When SBemu not loaded I got error on loading:
>
>(snip)
>
> When SBemu was loaded it rebooted immediatelly.
>
> MPXplay gives me error (regardless on SBemu):
> Program crashed (EXCEPTION ERROR) (bad environment, mpxplay.ini or audio
> file)

Doom is from 1993, and similarly DOS/4GW is also pretty old (even the later public or commercial versions). So it's not hugely surprising that they are incompatible, esp. since (as CWS mentions) they don't follow the DPMI spec closely enough and/or were buggy. CWSDPMI was not directly meant to be a universal "extender", only as close to compliant with the DPMI spec as possible, esp. for DJGPPv2 stand-alone use. (OpenWatcom 1.0 didn't appear until 2003 while CWSDPMI r1 was in 1996.)

In short, I know it'd be nice if everybody played well together, but they don't. In this particular example, if you really want to play Doom, you'd better use one of the (DJGPP + Allegro 3.x) open source ports (e.g. FreeDoom data via Eternity engine).

I'm not sure if Allegro supports your soundcard (unlikely for newer machines) but it's probably still better than original Doom, at least. But YMMV.

IIRC, the only DOS Doom port that works under XP seems to be CDoom (no nearptrs!), which has snippets of Allegro (but uses some other MIDI player, I forget which). I think it's alleged to be the smallest Doom .EXE, too. Vavoom uses MESA, but it's fairly slow. Boom is old and needs very old tools to recompile. In short, for normal Doom it matters less, but for FreeDoom your best bet (IMHO) is (recompiled w/ Allegro 3.10) Eternity 3.31 (bringing you VBE/AF and patches.dat support instead of only default patches.dat). FreeDoom explicitly needs a Boom-compatible, and IIRC Doom Legacy, Vavoom, etc. were too buggy or flat out incompatible. (MBF or SMMU, can't remember, one hated SB under DOSEMU, other must've had some issues too. Oh well.)

RayeR

CZ,
04.11.2010, 10:25

@ Rugxulo

MPXplay under CWSDPMI

Post reply

> In this particular example, if you really want to play Doom, you'd
> better use one of the (DJGPP + Allegro 3.x) open source ports (e.g.
> FreeDoom data via
> Eternity engine).

BTW is there compiled newer freedoom for dos? I have latest 1.41 and there's 1.42 and 1.44 beta but only for win32/linux..

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
04.11.2010, 12:20

@ RayeR

Post reply

> @Rugxulo: Thanks, but I don't want to play DOOM!

I know, I just wanted to clarify some notes about various engines, incompatibilities, etc. for anybody who's interested. (Oddly enough, Doom Legacy [not 100% Boom compatible??] and older, buggy FreeDoom were in FreeDOS 1.0, but they [Blair?] didn't show much interest in my comments. Yeah, well, the whole team is always too busy, ugh.)

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/doomx.lsm

EDIT: Seems "Doom Legacy" engine is barely still developed but hasn't had a proper DOS build since 2003, which basically means that (like all other ports) DOS support is dead, obsoleted, the new version is incompatible, and they won't change that. Sucks but usually true. (At least Eternity's dude was kind enough to be willing to accept patches if I rewrote the DOS backend, heh, as if.)

RayeR

CZ,
04.11.2010, 10:27
(edited by RayeR, 04.11.2010, 14:07)

@ Japheth

MPXplay under CWSDPMI

Post reply

> @Rugxulo: Thanks, but I don't want to play DOOM!

Then you're doomed spacemarine :)

---
DOS gives me freedom to unlimited HW access.

RayeR

CZ,
04.11.2010, 14:10

@ RayeR

MPXplay under CWSDPMI

Post reply

> MPXplay gives me error (regardless on SBemu):
> Program crashed (EXCEPTION ERROR) (bad environment, mpxplay.ini or audio
> file)

BTW MPXplay without DLL support doesn't suffer this problem. So I belive it's a problem of DLL handling stuff that rely on something in dos4g that is missing due to preloaded cwsdpmi...

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
06.11.2010, 19:17

@ RayeR

MPXplay under CWSDPMI

Post reply

I made some other investigation about cwsdpmi+mpxplay.

It really seems it is problem about DLL plugins. The DOS32A version of mpxplay works fine with cwsdpmi loaded.
I verified my claim that it is only mpxplay problem.
Tried DOOM, Duke3D, Baldies and Warcraft 2. They all worked OK except War 2 which started normaly but crashed after moving mouse.

However these games don't use DOS4G but DOS4GW extender.

I don't know if would help the change DOS4G to DOS4GW. Probably not.
I even don't know whether should be treated mpxplay or cwsdpmi. It seems it s rather bug in cwsdpmi.

Anyway, I have one feature request for mpxplay. Is possible to merge DLL capable and FTP capable versions?

---
DOS-u-akbar!

Mpxplay

08.11.2010, 12:31

@ Laaca

Post reply

> I am affraid I have no possibility to check out the DLL+TCPIP in real DOS
> now. I have here a DOS only machine I can even plug it into internet but my
> internet provider checks my MAC address and expect to find my notebook with
> windows. If I could fake the MAC address from DOS PC to my Win notebook I
> could check it.
> Or I can check it only in december when I return into my home with another
> DOS machine with fully working internet.

I've tested the new DOS4G/TCPIP version in test mode (-t) under XP with SWSVpkt (packet emulator). Seems to work.

Rugxulo Usono, 15.11.2010, 19:43 @ Mpxplay	Mpxplay v1.57 beta 9 is out Post reply
	> If nobody finds any tritical things, maybe this version will be the final > v1.57 (without source/binary changes). Please clarify: "final 1.57" (so work on 1.58 begins) or final DOS ever or final any ever?? I thought I remembered it being hinted that it would stall. And BTW, did you ever succeed in porting it to a newer version than OW 1.3 ?

Mpxplay

16.11.2010, 00:15

@ Rugxulo

Mpxplay v1.57 beta 9 is out

Post reply

Post reply

> The detection should start when I try to play 1 file, not be done in
> advance for all files, So if I try to play "BLAH.MP5" or "NOPE.TXT",
> MPXPLAY should look whether it is one of the supported audio or video file
> types.

1. I did want to make the less modifications in the old functions/routines
(because I have no time to test again everything if I modify something
in the source), so I implemented the "switch" in the in_file.c, which
has effect at every file open, at the pre-checking of files too (-idl, -ipl).
2. If you press enter on an unknown file and Mpxplay cannot play it,
then the program automatically skips to the next file. This works
on this way from many years (truely this is designed for skip-back/skip-forward keys)...

But I will think again on this function (at v1.58), maybe I will able to do something...

> BTW, if every file type had a reasonable sigi like PNG or FLAC, the
> content-autodetection would not be slow at all.

Not every. Only containers (AVI,MP4,WAV) And - for example - the FLAC also can contain an ID3v2 header. We have to skip that too.

Mpxplay has no fast content parsing (Mplayer has it), my program always read the complete header to detect/parse a file. This is slower, but sure way, even if the header/structure of the file/song is not correct.
Mpxplay supports 15 filetypes, if we want to detect a TXT file (that it's a non-audio file), we have to open the file and read the header 15 times.
btw. AAC is not autodetected in Mpxplay (detected by extension too), because it (the aac decoder for detection) is a little unstable.

Mpxplay 17.11.2010, 22:50 @ DOS386	Mpxplay v1.57 beta 9 is out \| WEBM Post reply
	> > > - OGG timing / seeking > > Where can I find such "wrong" OGG/OGM files? > > http://www.mozilla.com/en-US/firefox/video/ I don't see critical bugs at the first 5 video. The lengths of the files are correct, the seeking works, only the bitrate shows incorrect value. Just sometimes (in the default -bp mode) Mpxplay doesn't play the end of the file (2-3 secs are missing).

Mpxplay

26.11.2010, 05:44

@ Mpxplay

Mpxplay v1.57 final is out | Ogg problems

Post reply

> > > > - OGG timing / seeking
> > > Where can I find such "wrong" OGG/OGM files?
> >
> > http://www.mozilla.com/en-US/firefox/video/
>
> I don't see critical bugs at the first 5 video. The lengths of the files
> are correct, the seeking works, only the bitrate shows incorrect value.
> Just sometimes (in the default -bp mode) Mpxplay doesn't play the end of
> the file (2-3 secs are missing).

The good news: I've corrected it. (i've found an older and much worse file, probably you've sent it to me)
The bad one: not in the v1.57 final on http://mpxplay.sourceforge.net
You must wait till the next v1.58 (alpha) release...

Laaca

Czech republic,
04.12.2010, 21:09

@ Mpxplay

Mpxplay v1.57 beta 9 is out

Post reply

Now I finally made test if the new version with DLL and TCPIP together works.
Yes it does, everything runs fine, no regressions.

---
DOS-u-akbar!

Mpxplay 11.12.2010, 22:02 @ Laaca	Mpxplay v1.57 beta 9 is out Post reply
	> Now I finally made test if the new version with DLL and TCPIP together > works. > Yes it does, everything runs fine, no regressions. Thnx. Maybe I will release a DOS32A version too with TCPIP support... (if somebody really needs it) An interesting, but not so nice graph: http://www.google.com/insights/search/?hl=en-US#cat=5&q=mpxplay&cmpt=q

RayeR

CZ,
12.12.2010, 14:12

@ Mpxplay

Mpxplay v1.57 beta 9 is out

Post reply

> An interesting, but not so nice graph:
> http://www.google.com/insights/search/?hl=en-US#cat=5&q=mpxplay&cmpt=q
> :-(

I think it copy the graph of interest about all DOS stuff...

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
12.12.2010, 23:23

@ RayeR

Mpxplay v1.57

Post reply

> > An interesting, but not so nice graph:
> >
> http://www.google.com/insights/search/?hl=en-US#cat=5&q=mpxplay&cmpt=q
> > :-(
>
> I think it copy the graph of interest about all DOS stuff...

XP broke a lot, and Vista even worse. Seriously, I know that shouldn't matter so much, but it does. When even Windows didn't support it, many projects literally gave up.

But anyways, haven't you heard the old adage: "90% of statistics are made up" ?? ;-)

http://sourceforge.net/projects/freedos/files/Kernel/2039/stats/timeline

That link and graph shows that the 2039 kernel was downloaded 538 times in the past week.

http://sourceforge.net/projects/freedos/files/Kernel/

That one has a small icon you can hover your mouse over for each kernel. Assuming you believe everything you read (which you shouldn't, obviously??):

2039 2009-08-02 22,240 2038 2009-06-11 244 2036test 2006-05-21 55 2.0.35.a 2005-02-25 148 2.0.35 2004-05-30 89 2.0.34 2004-04-17 17

Now SERIOUSLY, who the hell believes those numbers are correct??? :-|

EDIT: BTW, weird to me that Freewebtown "mirror" isn't updated, still only has beta 9. I used to think that was more frequent / recent than SourceForge, but apparently that's changed lately. Oh well, whatever, just confusing.

Mpxplay

12.12.2010, 23:58

@ Rugxulo

Mpxplay v1.57

Post reply

> EDIT: BTW, weird to me that Freewebtown "mirror" isn't updated, still only
> has beta 9. I used to think that was more frequent / recent than
> SourceForge, but apparently that's changed lately. Oh well, whatever, just
> confusing.

Just I'm lazy... :-D
btw. there is no binary difference between beta 9 and final version.
And I hope I will able to release a v1.58 alpha in january, so that will be upladed to freewebtown...

DOS386

21.12.2010, 16:22

@ Rugxulo

Mpxplay v1.57 and 1.58

Post reply

> An interesting, but not so nice graph:
> http://www.google.com/insights/search/?hl=en-US#cat=5&q=mpxplay&cmpt=q

Dead link. Please post shot if it works for you in IE 10 - XXX64 :-(

> I think it copy the graph of interest about all DOS stuff...

So what :-\

> XP broke a lot, and Vista even worse. Seriously, I know
> that shouldn't matter so much, but it does.

It doesn't. I don't care about private problems of M$ :-)

Thanks to A.P. aka MPXPLAY for the answers and fixes (I haven't downloaded and tested yet, I will ASAP).

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

DOS386

24.12.2010, 08:45

@ DOS386

Seems to be about TENNIS rather than MPXPLAY

Post reply

> http://www.google.com/insights/search/?hl=en-US#cat=5&q=mpxplay&cmpt=q

[image] :clap:

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

Rugxulo

Usono,
25.12.2010, 01:11

@ DOS386

Mpxplay v1.57 and 1.58

Post reply

> Dead link. Please post shot if it works for you in IE 10 - XXX64 :-(

http://img822.imageshack.us/img822/8093/mpxplay.jpg

And for comparison ....

http://img202.imageshack.us/img202/7074/freedos.jpg

I did a few other searches too, apparently only big releases make much waves. E.g. Vista and Obama have both dropped significantly since their debut. :-P

EDIT: Okay, too big when inlined, sorry, I'll just make it plain links for the (barely) curious.

DOS386

26.12.2010, 09:21

@ Rugxulo

Mpxplay v1.57 and 1.58

Post reply

> http://img822.imageshack.us/img822/8093/mpxplay.jpg
> http://img202.imageshack.us/img202/7074/freedos.jpg

COOL, I see :-|

> I did a few other searches too, apparently only big releases make much
> waves. E.g. Vista and Osama have both dropped significantly

Userbase of STUXNET ??? :clap:

BTW, the userbase of my cool OS is currently ZERO, let's see whether it sinks further in future too :clap:

About MPXPLAY, tests:

* 1.57 final vs 1.57 beta 9 packaging: documented elsewhere, "SWSOCK.INI" missing
* Playing local files: OK (minimal test only)
* Playing files from internet (FTP/DHCP): not tested
* Playing files from other PC (FTP/fixed-IP): did not work (Arachne neither, Totalcommander did work ...)

Hints about how to fill in all the strange numbers (gateway, gateway2, gateway3, netmask, subnetmask, nameserver, nameserver2, ...) in "SWSOCK.INI" and Arachne for fixed IP usage are welcome ;-)

Issues "discovered" nevertheless:

- "SWSOCK.INI" no longer included

- MPXPLAY does not test for a packet driver, it "tries" FTP nevertheless.

- MPXPLAY does not complain about missing "SWSOCK.INI" (it does look for it, though), then it "tries" FTP nevertheless.

- No useful FTP addresses preselected / offered.

Solution:

- Delete "SWSOCK.INI" and move the useful content (DHCP vs BOOTP vs fixed IP, does it need more ???) into "MPXPLAY.INI", add some comments about how to use DHCP BOOTP and fixed IP

- Search INT $60 to INT $67 for a packet driver.

- Add some audio FTP sites (or is there just 1 ???) into "MPXPLAY.INI" and allow to pick them.

The enhanced FTP dialog could look like then:

Packer driver: found at INT $62 IP: 11.22.13.14 acquired using DHCP ftp://user:pasw@servername:port/dir or [F1] for list [# ]

or the evil case

Packer driver: NOT found IP: no entry in "MPXPLAY.INI" FTP not available !!!

PS: DOG4S needs almost 1'000'000'000 seeks to load MPXPLAY.EXE :-P

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

Laaca

Czech republic,
26.12.2010, 13:20

@ DOS386

Mpxplay v1.57 and 1.58

Post reply

I think it would be better to remove SWSSOCK.INI and to use WATTCP.CFG instead.
I know, it is CFG file for another library but this library is quite spread and is the facto standard for DOS programs.

And I think it is allways better to keep the nettwork settings for all DOS applications in one CFG file.

---
DOS-u-akbar!

DOS386

27.12.2010, 08:42

@ Laaca

Mpxplay v1.57 and 1.58 - INI and CFG stuff

Post reply

> better to remove SWSSOCK.INI and to use WATTCP.CFG instead
> and is the facto standard for DOS programs
> better to keep the network settings for all DOS applications in one CFG

Look for WATTCP.CFG, then SWSSOCK.INI, finally look into MPXPLAY.INI and remember where you found the stuff and whether it's Read-only.

If IP is acquired by DHCP then write it back (but not if R).

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

Mpxplay

27.12.2010, 17:24

@ DOS386

Mpxplay v1.57 and 1.58 - INI and CFG stuff

Post reply

> > better to remove SWSSOCK.INI and to use WATTCP.CFG instead
> > and is the facto standard for DOS programs
> > better to keep the network settings for all DOS applications in one CFG
>
> Look for WATTCP.CFG, then SWSSOCK.INI, finally look into MPXPLAY.INI and
> remember where you found the stuff and whether it's Read-only.
>
> If IP is acquired by DHCP then write it back (but not if R).

The handling of SWS_SOCK.INI is not my job, the SWSSOCK library reads it...
So ask the author of that lib, not me... ;-)
(I mean, maybe I can add a different INI filename to the SWSSOCK library, but probably it cannot handle the WATTCP.CFG file, because it uses different structure/variables)

btw. I've updated the MPXP157G.ZIP on http://mpxplay.sourceforge.net and added SWS_SOCK.INI file to it. thnx for the "bug report" :-)

DOS386

30.12.2010, 09:45

@ Mpxplay

Mpxplay v1.57 and 1.58 - INI and CFG stuff

Post reply

> The handling of SWS_SOCK.INI is not my job, the SWSSOCK library reads

There is "SwsSockSrc211.zip\SwsSockSrc\LIBS\sws_cfg.c" 22'433 2010-07-19 file apparently searching for "SWS_SOCK.INI" everywhere (path ? commandline ?) and reading the stuff and storing it (cleaned-up ?) into memory. So the solution could be to drop this file, and instead pick the stuff (3 hot lines cca ?) "on your own" from MPXPLAY.INI or WATTTCP.CFG or finally "SWS_SOCK.INI", as you already have some INI-file parsing code anyway.

BTW, seems to be very nice and well documented code, thanks to Lawrence Rust :-)

nevertheless I'm not an expert on C nor on this soccer&socks stuff :-(

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