For the DNS lookups it would be my intention to make it configurable in any
case, with a time interval, including one that never re-reads the config. In
my experience though, DNS lookups are pretty quick most of the time.
There are other potentially more complex methods that might not interrupt
the bridge, especially if they could be done asynchronously. But this has
the potential to affect the simplicity of the code, which may not be
desirable.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of hvlems at zonnet.nl
Sent: 20 November 2011 14:03
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] The Bridge
Adding a commandline switch is not difficult. Provided you're a programmer
of course. It won't affect the runtime performance.
Iwhich is why I'm against built-in DNS functionality. It will affect
performance
adversele for reason Johnny already mentioned. The program is now small,
well designed and performs accordingly. Improvements tend to deteriorate
performance.
Hans
-----Original Message-----
From: Mark Benson <md.benson at gmail.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 20 Nov 2011 13:22:01
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] The Bridge
On 20 Nov 2011, at 13:02, Johnny Billquist wrote:
While we are talking about improvements, would it be possible to make
it
search a few default locations on Linux/BSD for a config file? Currently
you
have to start it by cd-ing to the directory the binary is in as it looks
at the
current directory for the config file - if you start it from another place
if fails.
Perhaps looking in /etc/hecnet or another place you can specify at
compile time would be better?
That is easy. Just change the source before compiling, and there you
have it.
Definitely a compile time thingy, and extremely easy to "fix".
If you could make it a compile-time switch for make it would be very-much
nicer :) just something like 'CONFIG_FILE=/etc/hecnet' or something with a
commonly usable default value in case you forget to specify it or don't
want to
change it.
Also would it be difficult or counter-productive to roll the Port
configuration into the config file instead of having to specify it at
runtime?
If you don't want it on the command line, you can just assign it in the
code as
a constant. Very easy. :-)
That's easy for you to say, you're a coder. I don't code C at all and
wouldn't
know where to start, so if anyone else fancies na 'easy' challenge then
make it
so :)
I wouldn't want the port number hardcoded as it's configurable for a
reason
(it's a good thing), so it would be nice to have it read from the config
file
instead of having to remember it on the command-line.
Lastly does anyone know how to roll a init.d script for it to set it as
a service
in Debian/Ubuntu (10.04)?
Not sure which variant of init debian uses offhand, but in general you
just
write a small shellscript that don't do much more than just run the
command
line the same way you do by hand. Grab some other simple service and copy
the startup, and then change the command line.
It's ridiculously simple.
That I might be able to do. I'll look into it while I'm working out how to
make
one for SimH. Again though it's something I've not played with so some
helping hands along thew way would be nice ;)
I am going to have to try and write up tutorials for building the VAX and
PDP-
11 machines I have running as there isn't an up-to-date and comprehensive
tutorial for either, aside from Phil Werry's which is dated a little and
very hard
to read as it's very long and not broken up at all.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
I didn t, but suppose I should. I think that if I tidy up the code, then a simple diff will make the changes clear. Most of the work was to get PCAP and sockets to use the same mechanism to tell the code that there was some data to be processed.
Regards
Rob
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl Sent: 20 November 2011 11:24 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Windows Version of Bridge
Did you document the changes? I want to try and port it to VMS.
From: "Rob Jarratt" <robert.jarratt at ntlworld.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 20 Nov 2011 09:21:09 -0000
To: <hecnet at update.uu.se>
ReplyTo: hecnet at Update.UU.SE
Subject: [HECnet] Windows Version of Bridge
I just wanted to let you know that I have ported the bridge code to Windows. It seems to work well for me. If anyone is interested in a copy, let me know.
I think that it needs just a little bit more work to do the following:
1. Tidy up some bits that I almost certainly left behind while trying to get it to work.
2. Turn it into a Windows Service so that it starts automatically when Windows starts.
Another feature which would be nice to add generally is something which periodically re-resolves the DNS names in the config file to IP addresses, so that people who use something like DynDNS because they don t have a fixed IP address, can use it more easily and not fall off the network for too long when their IP address changes. Presumably calling the SIGHUP handler (read_conf) every so often would do the trick.
It would also be nice to make the code a bit more portable so that it will compile and run on more platforms without modification, a bit like SIMH.
Regards
Rob
Adding a commandline switch is not difficult. Provided you're a programmer of course. It won't affect the runtime performance.
Iwhich is why I'm against built-in DNS functionality. It will affect performance adversele for reason Johnny already mentioned. The program is now small, well designed and performs accordingly. Improvements tend to deteriorate performance.
Hans
-----Original Message-----
From: Mark Benson <md.benson at gmail.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 20 Nov 2011 13:22:01
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] The Bridge
On 20 Nov 2011, at 13:02, Johnny Billquist wrote:
While we are talking about improvements, would it be possible to make it search a few default locations on Linux/BSD for a config file? Currently you have to start it by cd-ing to the directory the binary is in as it looks at the current directory for the config file - if you start it from another place if fails.
Perhaps looking in /etc/hecnet or another place you can specify at compile time would be better?
That is easy. Just change the source before compiling, and there you have it. Definitely a compile time thingy, and extremely easy to "fix".
If you could make it a compile-time switch for make it would be very-much nicer :) just something like 'CONFIG_FILE=/etc/hecnet' or something with a commonly usable default value in case you forget to specify it or don't want to change it.
Also would it be difficult or counter-productive to roll the Port configuration into the config file instead of having to specify it at runtime?
If you don't want it on the command line, you can just assign it in the code as a constant. Very easy. :-)
That's easy for you to say, you're a coder. I don't code C at all and wouldn't know where to start, so if anyone else fancies na 'easy' challenge then make it so :)
I wouldn't want the port number hardcoded as it's configurable for a reason (it's a good thing), so it would be nice to have it read from the config file instead of having to remember it on the command-line.
Lastly does anyone know how to roll a init.d script for it to set it as a service in Debian/Ubuntu (10.04)?
Not sure which variant of init debian uses offhand, but in general you just write a small shellscript that don't do much more than just run the command line the same way you do by hand. Grab some other simple service and copy the startup, and then change the command line.
It's ridiculously simple.
That I might be able to do. I'll look into it while I'm working out how to make one for SimH. Again though it's something I've not played with so some helping hands along thew way would be nice ;)
I am going to have to try and write up tutorials for building the VAX and PDP-11 machines I have running as there isn't an up-to-date and comprehensive tutorial for either, aside from Phil Werry's which is dated a little and very hard to read as it's very long and not broken up at all.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 20 Nov 2011, at 13:02, Johnny Billquist wrote:
While we are talking about improvements, would it be possible to make it search a few default locations on Linux/BSD for a config file? Currently you have to start it by cd-ing to the directory the binary is in as it looks at the current directory for the config file - if you start it from another place if fails.
Perhaps looking in /etc/hecnet or another place you can specify at compile time would be better?
That is easy. Just change the source before compiling, and there you have it. Definitely a compile time thingy, and extremely easy to "fix".
If you could make it a compile-time switch for make it would be very-much nicer :) just something like 'CONFIG_FILE=/etc/hecnet' or something with a commonly usable default value in case you forget to specify it or don't want to change it.
Also would it be difficult or counter-productive to roll the Port configuration into the config file instead of having to specify it at runtime?
If you don't want it on the command line, you can just assign it in the code as a constant. Very easy. :-)
That's easy for you to say, you're a coder. I don't code C at all and wouldn't know where to start, so if anyone else fancies na 'easy' challenge then make it so :)
I wouldn't want the port number hardcoded as it's configurable for a reason (it's a good thing), so it would be nice to have it read from the config file instead of having to remember it on the command-line.
Lastly does anyone know how to roll a init.d script for it to set it as a service in Debian/Ubuntu (10.04)?
Not sure which variant of init debian uses offhand, but in general you just write a small shellscript that don't do much more than just run the command line the same way you do by hand. Grab some other simple service and copy the startup, and then change the command line.
It's ridiculously simple.
That I might be able to do. I'll look into it while I'm working out how to make one for SimH. Again though it's something I've not played with so some helping hands along thew way would be nice ;)
I am going to have to try and write up tutorials for building the VAX and PDP-11 machines I have running as there isn't an up-to-date and comprehensive tutorial for either, aside from Phil Werry's which is dated a little and very hard to read as it's very long and not broken up at all.
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On 2011-11-20 13.54, Mark Benson wrote:
On 20 Nov 2011, at 11:24, hvlems at zonnet.nl wrote:
Another feature which would be nice to add generally is something which periodically re-resolves the DNS names in the config file to IP addresses, so that people who use something like DynDNS because they don t have a fixed IP address, can use it more easily and not fall off the network for too long when their IP address changes. Presumably calling the SIGHUP handler (read_conf) every so often would do the trick.
Feel free. It's not overly complicated. However, make that optional, as maybe not all want that enabled. If DNS lookups take a while (which they definitely do when DNS is having problems), you'll hang the bridge while it's trying to resolve stuff.
It would also be nice to make the code a bit more portable so that it will compile and run on more platforms without modification, a bit like SIMH.
Any changes to make it more portable are always welcome. Just make sure you put the stuff in conditionals, so that the same source still compiles and works on the other platforms.
While we are talking about improvements, would it be possible to make it search a few default locations on Linux/BSD for a config file? Currently you have to start it by cd-ing to the directory the binary is in as it looks at the current directory for the config file - if you start it from another place if fails.
Perhaps looking in /etc/hecnet or another place you can specify at compile time would be better?
That is easy. Just change the source before compiling, and there you have it. Definitely a compile time thingy, and extremely easy to "fix".
Also would it be difficult or counter-productive to roll the Port configuration into the config file instead of having to specify it at runtime?
If you don't want it on the command line, you can just assign it in the code as a constant. Very easy. :-)
Lastly does anyone know how to roll a init.d script for it to set it as a service in Debian/Ubuntu (10.04)?
Not sure which variant of init debian uses offhand, but in general you just write a small shellscript that don't do much more than just run the command line the same way you do by hand. Grab some other simple service and copy the startup, and then change the command line.
It's ridiculously simple.
On 20 Nov 2011, at 11:24, hvlems at zonnet.nl wrote:
Another feature which would be nice to add generally is something which periodically re-resolves the DNS names in the config file to IP addresses, so that people who use something like DynDNS because they don t have a fixed IP address, can use it more easily and not fall off the network for too long when their IP address changes. Presumably calling the SIGHUP handler (read_conf) every so often would do the trick.
It would also be nice to make the code a bit more portable so that it will compile and run on more platforms without modification, a bit like SIMH.
While we are talking about improvements, would it be possible to make it search a few default locations on Linux/BSD for a config file? Currently you have to start it by cd-ing to the directory the binary is in as it looks at the current directory for the config file - if you start it from another place if fails.
Perhaps looking in /etc/hecnet or another place you can specify at compile time would be better?
Also would it be difficult or counter-productive to roll the Port configuration into the config file instead of having to specify it at runtime?
Lastly does anyone know how to roll a init.d script for it to set it as a service in Debian/Ubuntu (10.04)?
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
Did you document the changes? I want to try and port it to VMS.
From: "Rob Jarratt" <robert.jarratt at ntlworld.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 20 Nov 2011 09:21:09 -0000
To: <hecnet at update.uu.se>
ReplyTo: hecnet at Update.UU.SE
Subject: [HECnet] Windows Version of Bridge
I just wanted to let you know that I have ported the bridge code to Windows. It seems to work well for me. If anyone is interested in a copy, let me know.
I think that it needs just a little bit more work to do the following:
1. Tidy up some bits that I almost certainly left behind while trying to get it to work.
2. Turn it into a Windows Service so that it starts automatically when Windows starts.
Another feature which would be nice to add generally is something which periodically re-resolves the DNS names in the config file to IP addresses, so that people who use something like DynDNS because they don t have a fixed IP address, can use it more easily and not fall off the network for too long when their IP address changes. Presumably calling the SIGHUP handler (read_conf) every so often would do the trick.
It would also be nice to make the code a bit more portable so that it will compile and run on more platforms without modification, a bit like SIMH.
Regards
Rob
On Sun, Nov 20, 2011 at 4:21 AM, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
I just wanted to let you know that I have ported the bridge code to Windows.
It seems to work well for me. If anyone is interested in a copy, let me
know.
I think that it needs just a little bit more work to do the following:
1. Tidy up some bits that I almost certainly left behind while trying
to get it to work.
2. Turn it into a Windows Service so that it starts automatically when
Windows starts.
Another feature which would be nice to add generally is something which
periodically re-resolves the DNS names in the config file to IP addresses,
so that people who use something like DynDNS because they don t have a fixed
IP address, can use it more easily and not fall off the network for too long
when their IP address changes. Presumably calling the SIGHUP handler
(read_conf) every so often would do the trick.
It would also be nice to make the code a bit more portable so that it will
compile and run on more platforms without modification, a bit like SIMH.
Regards
Rob
Hello!
That's amazing Rob. Truly amazing. I've been stuck at that place found
in that cave adventure game, because I can't seem to figure out a
working method to connect something appropriate to the networking
setup that the list discusses.
Of course the next step for me, would be to setup something
appropriate...... Well maybe soon.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
I just wanted to let you know that I have ported the bridge code to Windows. It seems to work well for me. If anyone is interested in a copy, let me know.
I think that it needs just a little bit more work to do the following:
1. Tidy up some bits that I almost certainly left behind while trying to get it to work.
2. Turn it into a Windows Service so that it starts automatically when Windows starts.
Another feature which would be nice to add generally is something which periodically re-resolves the DNS names in the config file to IP addresses, so that people who use something like DynDNS because they don t have a fixed IP address, can use it more easily and not fall off the network for too long when their IP address changes. Presumably calling the SIGHUP handler (read_conf) every so often would do the trick.
It would also be nice to make the code a bit more portable so that it will compile and run on more platforms without modification, a bit like SIMH.
Regards
Rob
Thank You!
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Johnny Billquist
Sent: Saturday, November 19, 2011 9:48 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Macro32 entry forward desclaration - how?
On 2011-11-19 20:46, Pinoccio wrote:
Hi all!
I am studying Macro32 and have a seemingly simple question. My source file
is:
.TITLE tstentry
.IDENT /V1.0/
.PSECT RDATA,NOWRT,SHR,NOPIC,NOEXE,RD,QUAD
HI: .ASCID "Hello, World!"
.PSECT CODE,NOWRT,SHR,PIC,EXE,RD,QUAD
.ENTRY START, ^M<>
CALLS #0, PRINT
RET
.END START
.ENTRY PRINT
PUSHL HI
CALLS #1,G^LIB$PUT_OUTPUT
RET
.END PRINT
Macro32 decides PRINT is an external symbol, and link denies to produce
executable with a "LINK-W-USEUNDEF, undefined symbol PRINT referenced"
error. How I should make forward declaration of PRINT function to show
assembler it is valid local symbol? In C language I can make prototype
declaration before calling. But what is a right way for Macro 32?
You have misunderstood what .END does.
.END means assembly stops there, and the argument is the start address
of the program.
So, your code for your PRINT routine is not even assembled. Make sure
you create a list file, and this should be obvious.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
