On Thu, Jun 7, 2012 at 6:58 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 12:11 PM, Kari Uusim ki wrote:
There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6
client kit. Those versions were meant to be used on Windows'es before
Windows NT4. Then the Pathworks32 kit was released and that could be
used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for
sure.
Is this the same as DECnet-DOS? I ran that a long time ago. Does
anyone have a copy? It included drivers for that weird DEC ISA Ethernet
card, the DEPCA, which was a full-length 8-bit board that also included
(strangely) a mouse interface.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Oh my aching field density equalizers!
I have the programs for that thing. (Don't have the card.) I, ah, made
a copy of the programs onto a floppy from a PC/AT that I was repairing
for a customer, oh say about twenty years ago.
The customer, (not mine Dave the store I was working at) was a student
at one of the schools, (college) who had a remarkable DEC installation
running at it, it might have been Columbia. I found the card in it,
and asked the manager who was double checking my work, as was his
wont, and of course he didn't know what it was. I found out later what
it was, and yes it was what you've described.
Some years later I tracked down an old RACAL networking card and its
software, and they included a binary who took over for the code that
supported the hardware to talk to that stuff.
Obviously I never got the stuff to connect to a for real DEC setup,
but heck it would be fun to try and do so.
By the way Dave outside your door is a well dressed gentleman in a
suit that looks like something a certain outrageous poet and author
wore, and has hair to match. (Hint: its the same daft stuff I
sometimes pull on Sampsa.) There's also a blue colored box
outside.........
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 06/07/2012 12:11 PM, Kari Uusim ki wrote:
There is a DECnet stack for DOS and Windows in the Pathworks V5 or V6
client kit. Those versions were meant to be used on Windows'es before
Windows NT4. Then the Pathworks32 kit was released and that could be
used on WNT4.0 and Windows 2000. Maybe on XP as well. Don't remember for
sure.
Is this the same as DECnet-DOS? I ran that a long time ago. Does
anyone have a copy? It included drivers for that weird DEC ISA Ethernet
card, the DEPCA, which was a full-length 8-bit board that also included
(strangely) a mouse interface.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 06/07/2012 01:12 PM, Paul_Koning at Dell.com wrote:
Howabout starting it as a daemon (running as root) via the
boot scripts, and have non-root users's programs access it
via a socket?
Cool idea - you could even have multiple hosts connect this way
but export one DECNET endpoint, i.e. run CTERM on Box A whilst
FAL goes to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It
would open up all sorts of interesting configuration
possibilities.
... and all this without needing to dick with the kernel?
Sounds like a plan gentlemen, so now all we need is a long
suffering coder type to do all the hard work ;)
The main difference I can see vs. having the implementation in the
kernel is that the kernel one gives you an integrated API.
DecNET/Linux uses sockets, so an existing socket based app can be
made to run over DECnet with potentially very little work. On the
other hand, a userland implementation would need a different
mechanism for the communication between the application and the
DECnet daemon.
Hmm. Suddenly that approach doesn't sound very appetizing. :-(
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: 07 June 2012 07:27
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
Now, you have due permission to beat me with a dried haddock if I'm being
naive (I'm not a programmer, just a user observing a conversation that's
50%
over my head) but...
Wouldn't a kernel-agnostic DECnet implementation be a better shot? I mean
if you can skim DECnet packets using libpcap (which is kernel agnostic as
far
as I can tell, hell it even works on Windows :)) and use that to handle
DECnet
for the bridge or SimH what's stopping it being used for a full DECnet
comms
package? It might not be very *fast* and it's sure as hell not secure but
it'd
work, right?
With the fast pace of kernel change and the dropping of kernel support
(and
OSs like Ubuntu update the kernel regularly which will break things) for
DECnet in the 3.x kernel it may be that kernel-based support is no longer
practicable on modern Linux.
Just a thought...
This is such a big thread that it breached my attention span limit, so
apologies if I miss something.
This was exactly my plan, and I intend to give it a go, but no promises on
when I will have something.
I think it would be running a user-mode program running as root, use
promiscuous mode, and on linux/unix run as a daemon, while on Windows it
would run as a service. Being user mode it would be possible to run it on
multiple platforms with ease.
I am no DECnet expert, so I don't fully understand why I would need some
kind of other interface to the routing function, I got a bit lost when
people started talking about needing sockets to talk to the daemon. I think
I would probably just use a config file to drive it, rather than provide
some kind of command interface. Not sure if this would break something?
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: 07 June 2012 01:30
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] The bridge program...
On 2012-06-07 01:29, Rob Jarratt wrote:
As I have hacked my own copy around a bit to make it work on Windows,
can you tell me what the fix was as I may find it hard to locate your
change?
The port variable in the struct BRIDGE should be unsigned... :-)
What changes have you made? Maybe something that should be
incorporated in my sources?
Johnny
I can't remember exactly now, but it was mostly to get it to work on
Windows. I didn't do any fancy conditional compilation stuff on it for the
most part. I have attached it here.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: 07 June 2012 03:02
To: hecnet at Update.UU.SE
Cc: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Connections to SG1::
Hmm. Sure. But if you go the Linux routing route, then you instead get
into the problem that it don't have a point-to-point connection to
another Linux box on the Internet...
If anyone makes a Linux implemenation, I'll suggest that it would be made
to
support the Cisco/GRE and Multinet/UDP formats, and you could also have
Johnny's bridge on the other side....
-P
That is a good idea, I will take a look at doing that.
Regards
Rob
On 2012-06-07 19:40, Sampsa Laine wrote:
On 7 Jun 2012, at 18:12, Paul_Koning at Dell.com wrote:
The main difference I can see vs. having the implementation in the kernel is that the kernel one gives you an integrated API. DecNET/Linux uses sockets, so an existing socket based app can be made to run over DECnet with potentially very little work. On the other hand, a userland implementation would need a different mechanism for the communication between the application and the DECnet daemon.
Again it was suggested that the DECNET daemon listens on a socket, then you just plop the destination and/or listening details in via that mechanism - it's one line or so of code :)
But that is not enough. You need to read/write data, get notifications somehow, do out of band transmissions, accept, reject, connect and get information, and some more stuff. You need a protocol for talking to the daemon, no matter which way the communication actually pass back and forth between user programs and the daemon.
Johnny
On 7 Jun 2012, at 20:18, Kari Uusim ki wrote:
On 7.6.2012 20:12, Mark Benson wrote:
The last version of HP Pathworks 32 (7.2 I think?) works well in
Windows XP 32-bit.
I have a node that uses it but it's not switched on much.
The last version of Pathworks32 is V7.4 (I have the installation medium).
Haven't used Pathworks32 for many years anymore.
Maybe I would take it up again. :)
That's the one I meant :)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 7.6.2012 20:12, Mark Benson wrote:
The last version of HP Pathworks 32 (7.2 I think?) works well in
Windows XP 32-bit.
I have a node that uses it but it's not switched on much.
The last version of Pathworks32 is V7.4 (I have the installation medium).
Haven't used Pathworks32 for many years anymore.
Maybe I would take it up again. :)
On 7 Jun 2012, at 18:12, Paul_Koning at Dell.com wrote:
The main difference I can see vs. having the implementation in the kernel is that the kernel one gives you an integrated API. DecNET/Linux uses sockets, so an existing socket based app can be made to run over DECnet with potentially very little work. On the other hand, a userland implementation would need a different mechanism for the communication between the application and the DECnet daemon.
Again it was suggested that the DECNET daemon listens on a socket, then you just plop the destination and/or listening details in via that mechanism - it's one line or so of code :)
Sampsa
