DOS ain't dead

Don't ask me why, but I guess I got bored enough to "try" to use Arachne
in real FreeDOS. Usually I don't understand all the dumb settings, esp.
the router complications don't help. (sigh) So frustrating. Luckily,
this "old" P4 has RTL8139 ("rtspkt 0x60"), which is fairly common, so I had
hope! And it apparently works! I have no idea how, but whatever, good to test
(for once). So hello, blah, please ignore, just a test.

P.S. Now if only I knew how to shut the fan up. (XP knows, but it ain't
talking!)

> Don't ask me why, but I guess I got bored enough to "try" to use Arachne
> in real FreeDOS. Usually I don't understand all the dumb settings, esp.
> the router complications don't help. (sigh) So frustrating. Luckily,
>
> this "old" P4 has RTL8139 ("rtspkt 0x60"), which is fairly common, so I had
>
> hope! And it apparently works! I have no idea how, but whatever, good to
> test
> (for once). So hello, blah, please ignore, just a test.
>
> P.S. Now if only I knew how to shut the fan up. (XP knows, but it ain't
> talking!)

I still can run some network SW on my Realtek 8168 (8111) gbit eth. so I don't see any problem why it should not work (didn't tried arachne) :)

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

> > Don't ask me why, but I guess I got bored enough to "try" to use Arachne
> > in real FreeDOS. Usually I don't understand all the dumb settings, esp.
> > the router complications don't help. (sigh) So frustrating.

Arachne is my most used browser (MSDOS 6.20). And my most configurable !
Posting this with A1.90,r1. And her capabilities are still being expanded -
mostly by plug-ins. In a DOS forum, I am unsure why she is not better known.

> Arachne is my most used browser (MSDOS 6.20). And my most configurable
> !
> Posting this with A1.90,r1. And her capabilities are still being expanded
> -
> mostly by plug-ins. In a DOS forum, I am unsure why she is not better
> known.

I want to try the SVGALIB/Linux port on old ZipSlack too, but that will have to wait for another day. (I imagine it won't work, no huge surprise, incompatibilities suck.)

Arachne actually works better than I expected, but it's kinda slow on some sites. Also, some sites don't work fully correctly or use too much new-fangled, incompatible stuff (Javascript). So it's kinda a crap shoot. But anyways, the fact that it works at all is very very cool! I even took a bunch of screen caps of various sites with Boreal's SNARF TSR. (DOS386, how do you take your screens? BOCHS?) My guess is that it's probably not used more because nobody can find or setup their packet drivers. :-/

> I want to try the SVGALIB/Linux port on old ZipSlack too, but that will
> have to wait for another day. (I imagine it won't work, no huge surprise,
> incompatibilities suck.)

No, it won't work. It was a semi-proof-of-concept only. None of us have the
expertise to make a proper port. Any volunteers ?

> Arachne actually works better than I expected, but it's kinda slow on some
> sites. Also, some sites don't work fully correctly or use too much
> new-fangled, incompatible stuff (Javascript). So it's kinda a crap shoot.

Javascript is a real pain for DOS. It is possible to garner some of the
underlying links, and such, using a plug-in or two, but a full js capability
is beyond any of us developers.

> But anyways, the fact that it works at all is very very cool! I even took a
> bunch of screen caps of various sites with Boreal's SNARF TSR. (DOS386, how
> do you take your screens? BOCHS?)

Arachne has a built-in screen shot (PrintScreen button creates a .bmp).

> My guess is that it's probably not used
> more because nobody can find or setup their packet drivers. :-/

If there is a DOS packet driver for your nic, then Arachne can use it.
There are several collections of packet drivers available, but any new
ones will be welcome.

> > I want to try the SVGALIB/Linux port on old ZipSlack too, but that will
> > have to wait for another day. (I imagine it won't work, no huge
> surprise,
> > incompatibilities suck.)
>
> No, it won't work. It was a semi-proof-of-concept only. None of us have
> the
> expertise to make a proper port. Any volunteers ?

Hmmm, it doesn't work at all or only barely or ... ?

> Javascript is a real pain for DOS. It is possible to garner some of the
> underlying links, and such, using a plug-in or two, but a full js
> capability
> is beyond any of us developers.

No, I mean, that much was extremely obvious, I never expected anybody to actually do that. Some things even blind optimism can't conquer! Sad that simple hypertext has gotten so bloated, confusing, and complicated where you need gigs of RAM just to read text or download a file. What is it about modern society that makes them add so much fluff and superficiality to everything until it cracks under its own pressure?

> Arachne has a built-in screen shot (PrintScreen button creates a .bmp).

Sorry, I didn't read the docs or scrounge around too hard to find out, just tried what I knew would probably work (and did). But I did halfway suspect there was a built-in feature (easy to implement, I imagine).

> If there is a DOS packet driver for your nic, then Arachne can use it.
> There are several collections of packet drivers available, but any new
> ones will be welcome.

I know there are some, e.g. mostly from Crynwr, but sadly I think there are more network cards than packet drivers, and modern hardware incompatibility is such a PAIN! Argh! *shakes fist*

EDIT: Anyways, ignoring all the (off-tangent) gripes, big congrats to all the Arachne devs for their hard work, it's (still) impressive.

> I am unsure why she is not better known.

I think it is quite known but not very used because of hard usability.
The page loading is just very slow. (still messages like writing to disk, generating virtual screen, processing HTML atoms,....)

On my DOS machines I use very often the ELinks DOS browser. It is MUCH faster, can download multiple files on background and supports unicode and most national codepages without any settings.

---
DOS-u-akbar!

> If there is a DOS packet driver for your nic, then Arachne can use it.
> There are several collections of packet drivers available, but any new
> ones will be welcome.

BTW remember there are also wrappers that can translate different network APIs (packet<->ODI<->NDIS) one to another...

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

> I think it is quite known but not very used because of hard usability.
> The page loading is just very slow. (still messages like writing to disk,
> generating virtual screen, processing HTML atoms,....)

Yes, it takes time to download graphics then render the page.
If that is a bother, then Arachne can be run as text-only.

> On my DOS machines I use very often the ELinks DOS browser.

As do I, mostly for multiple downloads in background.
But I call Elinks from within Arachne whenever I need functions that
Arachne doesn't have natively. i.e. I use Elinks as an Arachne plug-in.

See also http://www.ausreg.com/arachne/ for some of the stuff that extends
Arachne's capabilities.

> > I think it is quite known but not very used because of hard usability.
> > The page loading is just very slow. (still messages like writing to
> disk,
> > generating virtual screen, processing HTML atoms,....)
>
> Yes, it takes time to download graphics then render the page.
> If that is a bother, then Arachne can be run as text-only.
>
> > On my DOS machines I use very often the ELinks DOS browser.
>
> As do I, mostly for multiple downloads in background.
> But I call Elinks from within Arachne whenever I need functions that
> Arachne doesn't have natively. i.e. I use Elinks as an Arachne plug-in.
>
> See also http://www.ausreg.com/arachne/ for some of the stuff that extends
> Arachne's capabilities.

Also have a look on my site in the apm directory.

http://glennmcc.org/apm/

APM == Arachne Package Manager

(Several of them were written by Ron)

---
--
http://glennmcc.org/

I tried to recompile arachne from source. The core.exe compiled fine but I have big problem with the Lopif graphics library. After I load the project and start build all it compile some 10ths of files and then crashes.



I tried to run under different memory managers and DOS 6.22, DOS 7.1, WinXP DOS BOX but always crashes. It maybe TASM problem not the BCC. Did someone else succeed?
p.s. Lopif sources are not inside arachne source I googled them elsewhere.

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

I remember few years ago I contributed by some small changes into core and did a full recompilation without any problem.
However I am not sure whether I also recomiled Lopif or just used the compiled .LIB file.

---
DOS-u-akbar!

> I tried to run under different memory managers and DOS 6.22, DOS 7.1, WinXP
> DOS BOX but always crashes. It maybe TASM problem not the BCC. Did someone
> else succeed?

Did you already try TASM32 instead of TASM?

---
MS-DOS forever!

> Did you already try TASM32 instead of TASM?

Well, I fixed it by upgrading my TASM. I found TASM 5.0 install package with 5.3 updates but TASM.EXE for DOS is ver. 4.1. My TASM was even older 4.0. Now it compiles (with some warnings) and recompiled binary seems to run.

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

> > Arachne has a built-in screen shot (PrintScreen button creates a .bmp).
>
> Sorry, I didn't read the docs or scrounge around too hard to find out, just
> tried what I knew would probably work (and did). But I did halfway suspect
> there was a built-in feature (easy to implement, I imagine).

Didn't work for some reason, maybe I'm lacking something (APM)?? Dunno, will have to try again later. (I'm honestly not even sure how to install an APM, guess I gotta read some stuff. And I see "fedit" would be nice to edit/create ISO-8859-3, which is sadly lacking, apparently. Oh well, I don't "need" it, just saying ....)

> > Did you already try TASM32 instead of TASM?
>
> Well, I fixed it by upgrading my TASM. I found TASM 5.0 install package
> with 5.3 updates but TASM.EXE for DOS is ver. 4.1. My TASM was even older
> 4.0. Now it compiles (with some warnings) and recompiled binary seems to
> run.

http://en.wikipedia.org/wiki/Talk:Turbo_Assembler

"TASM is still bundled with Embarcadero C++ Builder and Delphi products. The current version (shipping with 2010 versioned products) is 5.4, Copyright 2009 to Codegear. Therefore, the statement that TASM is no longer maintained is inaccurate."

BTW, Code Gear's Turbo C++ 2006 was "freeware", which is where I grabbed TASM32 5.3 (circa 2000), even though the whole thing didn't install at all (annoying). However, Embarcadero neither hosts that older version nor gives away newer free ones.

There are various TASM-y clones, all of different abilities (none complete), e.g. WASM -zcm=tasm, YASM -ptasm, NoMySo (via Perl) converter, LZASM, etc.

EDIT: Hmmm, "but TASM.EXE for DOS", I do recall that 5.3 was a hybrid .EXE, 32RTM-ish, though I didn't see that (nor DPMI*.OVL), no huge surprise, so I think I ended up running under HX or just using WDOSX's STUBIT on it. It seemed to work fine then, if you're trying to run in real/pure/native DOS.

> how do you take your screens? BOCHS?

RTFW (scroll down to "Screenshooting & screenshots")
RTFW
RTFW

> My guess is that it's probably not used
> more because nobody can find or setup their packet drivers.

More reasons:

1. obsession by M$-IE (NOT a browser)
2. obsession by Fla$H
3. faulty pages not working with Arachne (Fla$H, Java$hit, ...)
4. no file upload, no HTTPS, ...
5. nobody has DOS, no point to use Arachne in Windaube&Co

If anyone successfully recompiles Arachne from source, please boast

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

Hi, I just successfully modified arachne and lopif source to support
higher vesa modes 1280x1024/Hi and 1600x1200/Hi to fit my display in
native mode and posting from it now :)
I'd also like to add support for mouse-wheel scrolling. I heard that
ctmouse can handle is so could I get scroll event through mouse api (i
guess int 33h)?

> Hi, I just successfully modified arachne and lopif source to support
> higher vesa modes 1280x1024/Hi and 1600x1200/Hi to fit my display
> in native mode and posting from it now

COOL Will you release your binary + complete source code and compiling instructions (tools used, ...) ?

> I'd also like to add support for mouse-wheel scrolling.

For me it already works

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

> > I'd also like to add support for mouse-wheel scrolling.
>
> For me it already works


Yes, it is already implemented.
I even made some fixes in mouse wheel handling few years ago.

---
DOS-u-akbar!

> Yes, it is already implemented.
> I even made some fixes in mouse wheel handling few years ago.

Already implemented? But it doesn't work on my mouse (intelli mouse optical explorer 3.0). where can I enable it in config?

After I do some cleaning my debug stuff I will release it. As I walk thorugh code it is very old and entire VESA handling should be rewritten. There are some internal harcoded tables that doesn't allow futher extensing - should be replaced by dytnamic mode list. Also support for truecolor modes would not be fun because you need modify also assembles files. But I don't have more time to work on it. It would be better if possible to grab sources of DR-Webspyder - AFAIK it was converted to DJGPP :)

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

> Already implemented? But it doesn't work on my mouse (intelli mouse optical
> explorer 3.0). where can I enable it in config?

IIRC it's enabled in Arachne, rather RTFM about CTMOUSE.

> After I do some cleaning my debug stuff I will release it.



> As I walk thorugh code it is very old and entire VESA handling should be rewritten.
> There are some internal harcoded tables that doesn't allow futher extensing
> - should be replaced by dytnamic mode list.

Does it use hardcoded mode numbers (VESA 1.x style) ?

> It would be better if possible to grab sources of DR-Webspyder
> AFAIK it was converted to DJGPP

Possibly true, but it was split off in 1998, so drop all Arachne
development since that time. Also, that code is not free.

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

> IIRC it's enabled in Arachne, rather RTFM about CTMOUSE.

Oh yes, I didn't have /O switch as I don't use any other program that support it. It works now, thx.

> Does it use hardcoded mode numbers (VESA 1.x style) ?

Yes it use only VBE 1.x modes, no LFB. There's problem that modes higher than 1024x768 doesn't have fixed mode numbers. I compared it on modern nvidia and ATI and they are different. I'll probably do some quick hack that allows you to override mode number in some config file...

Now I found that printscreen doesn't work in my higher modes and totally mess up the screen. I'll try to fix it but not much interested in this feature. It's evil search through whole code to chceck what else may be affected...

> Possibly true, but it was split off in 1998, so drop all Arachne
> development since that time. Also, that code is not free.

I know but maybe some pirates, leaks, etc...

BTW I use Realtek 8111 ODI driver with packet wrapper and works well:

LOADHIGH lsl
LOADHIGH rtgeodi
rem odipkt [frame number of Ethernet_II in net.cfg from 0] [Packet INT service in decimal 96=0x60]
LOADHIGH odipkt 1 96


But I have some problem with DHCP (as with most progs that use WATTCP library) it simply doesn't configure and I have to use fixed address that I grab via ipconfig /all from windows. As I don't have fixed IP it's not ideal but fortunately my IP is changing not so often. For more comfort I could make some small tool to parse it and generate wattcp.cfg.
It's specific issue of this library because SWSOCKS configure automatically without problem...

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

The printscreen bug was simply cause by too small line buffer. It's piggy code with a lot of hardcoded stuff. Anyway, now it's fixed. You can download it here (including sources)
http://rayer.ic.cz/download/arachne.rar

see arachne\sources\!readme.txt for compiling instructions and overriding vesa mode numbers.

a screen of BTTR in arachne 1600x1200 http://rayer.ic.cz/350d/arachne.png :)

EDIT by rr: fixed URLs

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

> The printscreen bug was simply cause by too small line buffer. It's piggy
> code with a lot of hardcoded stuff. Anyway, now it's fixed. You can
> download it here (including sources)
> http://rayer.ic.cz/download/arachne.rar
>
> see arachne\sources\!readme.txt for compiling instructions and overriding
> vesa mode numbers.
>
> a screen of BTTR in arachne 1600x1200 http://rayer.ic.cz/350d/arachne.png
> :)
>
> EDIT by rr: fixed URLs


Fantastic !!!

My vid card can't do 1600x1200...
but I just tested it at 1280x1024 and it works perfectly.

THANK YOU !!!

---
--
http://glennmcc.org/

> You can download it here (including sources)
> http://rayer.ic.cz/download/arachne.rar
> see arachne\sources\!readme.txt for compiling instructions and overriding
> vesa mode numbers.
> a screen of BTTR in arachne 1600x1200 http://rayer.ic.cz/350d/arachne.png

COOL I'll test

PS: Why the **** is this in "sandbox" ???

PPSS: BUG's

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

Hi all,

Good to see some continued interest in Arachne.
If any of you are curious, I have a forked version that has
a few advantages over the stock line. Probably the majority of
Arachne users in the past were opposed in principal to my forking the
code, so I quite understand if no one wants to touch it, but if anyone
does want to have a look, the main points are:

ca. 200K less memory required.
automatic charset selection.
better setup.
complete rewrite of SRC
full integration of xlopif and wattcp libraries
no 'build all' problems
dozens of little bug fixes
basically smoother GUI operation

If I could get someone to give me a hand with TASM, it wouldn't
take long to get the thing ready for porting to 32 bit. I started
getting it NASM compatible, but I know only the first things about ASM,
so I didn't get very far. In the old days I had Michal Tyc and nothing was
impossible

Oh, a few things that some have hated:

Removal of support for museum class hardware (CGA, EGA, <386 processor, etc.)
Small changes to key assignments.

> Hi all,
>
> Good to see some continued interest in Arachne.
> If any of you are curious, I have a forked version that has
> a few advantages over the stock line. Probably the majority of
> Arachne users in the past were opposed in principal to my forking the
> code, so I quite understand if no one wants to touch it, but if anyone
> does want to have a look, the main points are:
>
> ca. 200K less memory required.
> automatic charset selection.
> better setup.
> complete rewrite of SRC
> full integration of xlopif and wattcp libraries
> no 'build all' problems
> dozens of little bug fixes
> basically smoother GUI operation
>
> If I could get someone to give me a hand with TASM, it wouldn't
> take long to get the thing ready for porting to 32 bit. I started
> getting it NASM compatible, but I know only the first things about ASM,
> so I didn't get very far. In the old days I had Michal Tyc and nothing was
> impossible
>
> Oh, a few things that some have hated:
>
> Removal of support for museum class hardware (CGA, EGA, <386 processor,
> etc.)
> Small changes to key assignments.

Damn, that I didn't know this before few days. I could spent effort on much more fresh version. You did also some enhancement to VESA code? It would be nice to turn it fully into 32bit code like DR-Webspyder (prefer DJGPP/NASM) and clean up old things (I would mind about <VGA). Also wattcp could be replaced by modern SWSSOCKS. I don't have much time to work on it but if you will share your code just to test it. For the ASM there are better gurus here than me, I only use NASM a little bit and forgot TASM syntax.

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

RayeR:

> Damn, that I didn't know this before few days. I could spent effort on much
> more fresh version. You did also some enhancement to VESA code? It would be

Only small changes to VESA.

> nice to turn it fully into 32bit code like DR-Webspyder (prefer DJGPP/NASM)

Right, DJGPP would be the target compiler.

> and clean up old things (I would mind about <VGA). Also wattcp could be

It was a difficult decision what to keep and what to cut. Basically, because I
made so many changes, I decided to only keep hardware support that could be tested, so much hardware support for old hardware had to go. However, the simplified code thus becomes much easier to work with, and old code can always be restored if needed.

> replaced by modern SWSSOCKS. I don't have much time to work on it but if

I knew there were optimizations to be made in the libraries as well as the CORE SRC, so I integrated everything, but of course that's not too hard to undo and use more modern code.

> you will share your code just to test it. For the ASM there are better

Of course. I'll get something together and let you know.

> gurus here than me, I only use NASM a little bit and forgot TASM syntax.

> > > Arachne has a built-in screen shot (PrintScreen button creates a
> .bmp).
>
> Didn't work for some reason, maybe I'm lacking something (APM)??

Okay, guess I have to specify a path, e.g. "download\PAGE.BMP" then export. Similar to SNARF, it's a very huge .BMP, so converting to a better format via PictView is encouraged.

(And just for clarity ...)

> PS: Why the **** is this in "sandbox" ???

Where else should I have posted it? It wasn't a very informative post, nor a request for anything. Perhaps "Users" or "Miscellaneous"?? As mentioned, it was just a rough test, so "Sandbox" seemed appropriate.

>
> If I could get someone to give me a hand with TASM, it wouldn't
> take long to get the thing ready for porting to 32 bit. I started
> getting it NASM compatible, but I know only the first things about ASM,
> so I didn't get very far. In the old days I had Michal Tyc and nothing was
> impossible

I've often stumbled over TASM code, even tried converting various things to NASM, mostly without success. Probably because I never knew TASM to begin with (and am quite a wimpy coder myself). My best guess at this point would be to use OpenWatcom's WDIS on the TASM .OBJ, it's probably the best help you can get. :-/

EDIT: Unless, as mentioned, you can get one of the following to work instead: WASM -zcm=tasm, LZASM, NoMySo.

> PS: Why the **** is this in "sandbox" ???

Uh I finally got this note I wondered before, just becasuse I view the forum all categories on one page (there are not much new messages) so don't care about categories and even didn't know there's sandbox :)

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

I wrote:

> I'll test

Done! Works (modes added, 1600x1200 throws me back (great card doesn't support it ???), 1280x1024 runs, but horrible deformation of the screen (great monitor doesn't like it ???), so I pushed RESET before I got some fire

rayandrews wrote:

> I have a forked version that has a few advantages over the stock

Where to download ?

> ca. 200K less memory required

??? really 200 KiB of low memory saved ???

> automatic charset selection.
> better setup.
> complete rewrite of SRC
> full integration of xlopif and wattcp libraries
> no 'build all' problems
> dozens of little bug fixes
> basically smoother GUI operation

COOL

> Oh, a few things that some have hated:
> Removal of support for museum class hardware
> (CGA, EGA, <386 processor, etc.)

I like the 8086 version too (but the museum drivers should get split out).

> DJGPP would be the target compiler.

Why not WATCOM ? One compiler for both the 8086 and the 32-bit version

> Okay, guess I have to specify a path, e.g. "download\PAGE.BMP" then export.

RTFW, see above.

> Similar to SNARF, it's a very huge .BMP, so converting to
> a better format via PictView is encouraged.

NO. Use PNGOUT or OPTIPNG (needs HX+UI21DEB)

> > PS: Why the **** is this in "sandbox" ???
> Where else should I have posted it?

Maybe Users? Developers?

> It wasn't a very informative post

Maybe, but it was DOS-related at least

> so "Sandbox" seemed appropriate.

there are other bloated threads ...

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

> Done! Works (modes added, 1600x1200 throws me back (great card doesn't
> support it ???), 1280x1024 runs, but horrible deformation of the screen
> (great monitor doesn't like it ???), so I pushed RESET before I got some

And did you tried to override vesa mode number for 1600x1200 mode (readed the readme)? Probably your VGA has different mode number or dont't support it at all :P But if your monitor can't even withstand 1280x1024 then don't try it or you will blow off your vertical deflection power transistor

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

> override vesa mode number for 1600x1200 mode (readed the readme)?

YES. But I need better PC + better monitor to test 1600x1200

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

> I wrote:
>
> > I'll test
>
> Done! Works (modes added, 1600x1200 throws me back (great card doesn't
> support it ???), 1280x1024 runs, but horrible deformation of the screen
> (great monitor doesn't like it ???), so I pushed RESET before I got some
> fire
>
> rayandrews wrote:
>
> > I have a forked version that has a few advantages over the stock
>
> Where to download ?
>
> > ca. 200K less memory required
>
> ??? really 200 KiB of low memory saved ???
>
> > automatic charset selection.
> > better setup.
> > complete rewrite of SRC
> > full integration of xlopif and wattcp libraries
> > no 'build all' problems
> > dozens of little bug fixes
> > basically smoother GUI operation
>
> COOL

DOS386,

I have been busy at work the last few days, I'll get that uploaded soon. However,
Glenn McC has always hosted it on his site, but it's not usually visible on his homepage. I can't remember the URL right now, I have to boot DOS to find it. You can ask at AQCCC.

BTW, the above progress has not come cheep, there are always bugs in my core due to a low number of testers and I run some dangerous experiments. If you work with my fork you must expect some pain, ask Ron, Eric, and Glenn )

> Glenn McC has always hosted it on his site, but it's not usually visible

Space for improvements ? Document than Glennmcc doesn't develop Arachne anymore since 1.95 release in 2008-Dec, but RayAndrews does, plus link

> If you work with my fork you must expect some pain

I'll test (as soon as I find something to test)

BTW: is there a version history (up-tp-date, ending in 2011) ?

PS: did you really save 200 KiB of low memory ?

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

> > Glenn McC has always hosted it on his site, but it's not usually visible
>
> Space for improvements ? Document than Glennmcc doesn't develop Arachne
> anymore since 1.95 release in 2008-Dec, but RayAndrews does, plus link

I just looked at Glenn's site 'www.glennmcc.org' but I see no reference to my
fork, where did you see that?
>
> > If you work with my fork you must expect some pain
>
> I'll test (as soon as I find something to test)
>
> BTW: is there a version history (up-tp-date, ending in 2011) ?
>
> PS: did you really save 200 KiB of low memory ?

About. It's hard to give an exact figure since my core grabs all the memory it needs on startup
whereas std. core grabs memory as needed via malloc(), thus, std. core requires a lot of 'free memory' to run, whereas my 'free memory' is really *free* -- you can use all of it for other things like TSR's and the core is unaffected. But, with std. core, if 'free memory' drops below a certain point, sometimes it will crash, sometimes just slow down, so it's hard to make an exact comparison. Std. core has a 'red zone' with free memory below 160K IIRC, but I have none, since 'free' is really free.

> > BTW: is there a version history (up-tp-date, ending in 2011) ?

For several years I kept a good record of changes, but after that, since so few people were using my version, I let it stop, but that was a mistake, since now even I forget all the things I did

> > > BTW: is there a version history (up-tp-date, ending in 2011) ?
>
> For several years I kept a good record of changes, but after that, since
> so few people were using my version, I let it stop, but that was a mistake,
> since now even I forget all the things I did

OK, my stuff can be found at: www.glennmcc.org/rayandrews
a recent distro is: ray_a4e.zip
fairly recent SRC: 2k-38src.zip

files like: 2j-31.zip are more recent cores.
My big problem right now is that I may be suffering from a memory
corruption problem, since when I change cores, I can end up unstable.
I'm having trouble figuring out where this starts, or even if changing
cores after the packet driver is loaded would be expected to cause
trouble anyway.

Note, a new core will almost always come with a file named keywords.xxx
which is essential, it just stores data only used on startup (keywords and
default values) thus not built into the .exe -- it saves a small amount of
memory.

> I just looked at Glenn's site 'www.glennmcc.org' but I see no
> reference to my fork, where did you see that?

This was a suggestion, not detection

But seems it got just added in the meantime

> > PS: did you really save 200 KiB of low memory ?
> About. It's hard to give an exact figure since

Glennmcc disagrees, see other forum

> OK, my stuff can be found at: www.glennmcc.org/rayandrews
> a recent distro is: ray_a4e.zip

CORE.EXE 2008-07-29 So your distro is even older than Glennmcc's 2008-Nov/Dec release

> fairly recent SRC: 2k-38src.zip

2010-11-23

> files like: 2j-31.zip are more recent cores

2010-12-03 - better now

> Note, a new core will almost always come with a file named keywords.xxx
> which is essential, it just stores data only used on startup (keywords and
> default values) thus not built into the .exe - it saves a small amount of memory.

The latest one has none.

BTW, is there a system behind your file naming ? I can't discover any ...

Maybe "RA080729.ZIP" (distro) , "CS101123.ZIP" (core source) , "CB101203" (core binary) ?

I'll test the 2010-12-03 core occasionally.

I see that you removed the libraries and turned the source into one "flat" package of C and H and ASM files, but no compiling instructions or requirements. Any chance to upgrade the compiler to WATCOM ? WATCOM could compile both an 8086 version and a 32 bit version too

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

>
> Glennmcc disagrees, see other forum

Ok, we can argue about it there. As I said, the exact amount is
hard to say. As it is now, my core uses maxed out stack (64K) although
32K is probably fine, also, several buffers are now bigger than needed.
At times my core has given 230K free. Anyway, you will see for yourself.
Load TSR's till 'free memory' is almost zero, and there will be no
problem.

>
> CORE.EXE 2008-07-29 So your distro is even older than Glennmcc's
> 2008-Nov/Dec release
>
I haven't done any work for a few months.


>
> The latest one has none.


Better not play with the latest cores, they are buggy fo sure!

>
> BTW, is there a system behind your file naming ? I can't discover any ...
>

I should have a better system. But names for cores follow a very careful
pattern: "2k-45"

'2k' is 'major build' this indicates a new keywords file, and that I have
backed up to a new arachive directory here. No one needs to know about
that but me, of course, but I do need to know it.

'45' is 'minor build', after '99' it cycles back to '10'. In my sources
backups are done with just two letters:

main.c45
init.c45
guievent.c45


thus, I have dozens of 'guievent.c45' over the years. The 'major build' is
thus the name of the directory in which any set of backups can be found:


\arachne\core\builds\2j\*.c??
\2k\*.c??
etc.


Anyway, it lets me keep track of everything. I can restore any build going
back years in just a few seconds.



> I see that you removed the libraries and turned the source into one "flat"
> package of C and H and ASM files, but no compiling instructions or
> requirements. Any chance to upgrade the compiler to WATCOM ? WATCOM could

Right, it is perfectly flat, no special compiler pragmas or anything. This
made it possible to integrate the libs much more tightly, since there's no
need to go through 'official channels' to get at the functionality.

> compile both an 8086 version and a 32 bit version too


Well, these are all things to explore. I've never used WATCOM myself, but
of course it's all open to discussion. I had been thinking about DJGPP,
and for that I was trying, as I said, to get the ASM ported to NASM, and I
did some work, but much more to do. Especialy, I don't know how to edit
the ASM for 32 bit instructions.

BTW, anyone who tries my distro should note that most .APMs won't work
right out of the box since my directory structure is different, but they
are easy to fix.

> Better not play with the latest cores, they are buggy fo sure!

What to test ?

> Well, these are all things to explore. I've never used WATCOM myself, but
> of course it's all open to discussion. I had been thinking about DJGPP

Fred uses DGJPP:

+ 32-bit version exists and works, and HTTPS/SSL added
- missed the chance to get completely rid of Boreland C
- source must be compatible with very different 2 compilers
- crappy C lib

> did some work, but much more to do. Especialy, I don't know how to edit
> the ASM for 32 bit instructions.

The problem are not that much 32-bit instrucsions, but more likely the protected mode:


   mov  ax, $A000 ; VGA area
   mov  ds, ax    ; RM: fine | PM: GPF !!!


16-bit registers do work in 32-bit mode too, they are just hell slow (optimize later !!!).

I could help with the PM (and with VESA mode search), but I have no experience with C+ASM mixing using a linker

When did you split your fork from Glennmcc's one ? Did you at least exchange some patches after ?

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

DOS386,

Sorry for taking time with this reply, I've been busy at work.

> > Better not play with the latest cores, they are buggy fo sure!
>
> What to test ?

ray_a4e.zip is the complete package, including a stable core.
g1.zip is a bit more recent but more experimental.


>
> The problem are not that much 32-bit instrucsions, but more likely the
> protected mode:
>
>
> mov  ax, $A000 ; VGA area
> mov  ds, ax    ; RM: fine | PM: GPF !!!
>
>
> 16-bit registers do work in 32-bit mode too, they are just hell slow
> (optimize later !!!).
>

Sure, I think that's what I meant, but this is all beyond my
knowledge. All I know is that there's some work to do.

> I could help with the PM (and with VESA mode search), but I have no
> experience with C+ASM mixing using a linker
>
That's were we need some more help.

> When did you split your fork from Glennmcc's one ? Did you at least
> exchange some patches after ?

Sure, dozens of them. Wherever Glenn likes some fix of mine he imported it to 1.9x
branch. Apart from the improved video resolution just done, the last patch of 1.95 was
due to a fix from me just last month, what we called the 'slow .gif' bug.

As to the fork. At first my goal was to just clean up the old source code, which, as everyone knows is famous for being the worst mess anyone ever saw. What I called 'base 1' produced an identical .exe but had proper formating and removal of dead contitionals (#ifdef AGP, etc.)
In those days we had several developers, and about half preferred my code, and the other half preferred to use the old ones. I had no thought to create a 'fork' as such, but the 'clean code' developers started doing work, and it just gradually got more and more different. I imported every improvement of 'dirty code' fork but the opposite is not always true. Basically the 'dirty code' people thought nothing should ever be removed from the old SRC incase it turned out to be useful some day. The 'clean code' people thought anything useful could just be restored if needed, and so it is to this day.

> As to the fork. At first my goal was to just clean up the old source code,
> which, as everyone knows is famous for being the worst mess anyone ever
> saw. What I called 'base 1' produced an identical .exe but had proper
> formating and removal of dead contitionals (#ifdef AGP, etc.)
> In those days we had several developers, and about half preferred my code,
> and the other half preferred to use the old ones. I had no thought to
> create a 'fork' as such, but the 'clean code' developers started doing
> work, and it just gradually got more and more different. I imported every
> improvement of 'dirty code' fork but the opposite is not always true.
> Basically the 'dirty code' people thought nothing should ever be removed
> from the old SRC incase it turned out to be useful some day. The 'clean
> code' people thought anything useful could just be restored if needed, and
> so it is to this day.

Yes I understand, hard decision between code clarity and innovations vs strict backward compatability. I think that rich features incl. legacy stuff maky be kept together but it requires well structured and modular code arch. And it's hard to keep it together when done by many people...

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

> ray_a4e.zip is the complete package, including a stable core



There is a "Corrupt-BLACK-BUG"

> > When did you split your fork from Glennmcc's one ? Did you at least
> > exchange some patches after ?
> Sure, dozens of them. Wherever Glenn likes some fix of mine he imported it
> to 1.9x branch. Apart from the improved video resolution just done, the last patch
> of 1.95 was due to a fix from me just last month, what we called the 'slow .gif' bug.

But Glennmcc's 1.95 is dead since 2008-Nov/Dec ? Downloaded: installer EXE is 2008, CORE.EXE inside 2009

Thanks for the "documentation" provided in this thread (packaged with Arachne would be even better).

BTW, Glennmcc's has a strange "no 16bpp if C: is full - BUG"

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

>
> There is a "Corrupt-BLACK-BUG"
>
Sorry, I don't know what you mean -- but I can see those colors are
totally wrong. I'm In linux right now, I'll try loading this from DOS
and see what happens.


> But Glennmcc's 1.95 is dead since 2008-Nov/Dec ? Downloaded: installer EXE
> is 2008, CORE.EXE inside 2009

Maybe coming to life again
What do you mean 'installer EXE?


>
> Thanks for the "documentation" provided in this thread (packaged with
> Arachne would be even better).
>
My documentation is virtually nothing because I wanted to get it finalized before documenting it. Especially the directory structure. BTW, I forgot to mention, my core is designed for easy translation into other languages than English. We had a Russian version up to date until about two years ago. Almost all text is found in 'mess-eng.c / messages.h' and somewhere you will find 'mess-rus.c'. It would be maybe a few days work to translate it into
Deutsche or Czech.


> BTW, Glennmcc's has a strange "no 16bpp if C: is full - BUG"

DOS386,

>
> > There is a "Corrupt-BLACK-BUG"
> >

OK, I see what you mean. That bug is fixed in more recent cores, but I
have new bugs as well in the more recent cores. Give me some time to get
rid of the bugs I know, and I'll upload a recent core.

BTW, if I know you are at your computer, we can work faster using Glenn's
aqccc board, since it's so quick and easy to post, almost like talking on
the phone. More important stuff should be here of course.