NOTE: IceEdit 2.35 M16251
Hello all,

Another file area question for you.
I have one area for BBS doors, and whenever I use a utility to import the file_id.diz descriptions fbp.exe fails when it gets to the door area.

Is there anyway to make FBP log what's going on so I can delete the offending
file? Right now I just have to have all descriptions blank to make it continue
through the rest of the areas.

Thanks,

... A modest man is usually admired - if people ever hear of him.

---
* Origin: Tiny's BBS t1ny.kicks-ass.org Back/2! (1:229/452)

NOTE: IceEdit 2.35 M16251
Hello all,

Another file area question for you.
I have one area for BBS doors, and whenever I use a
utility to import the file_id.diz descriptions fbp.exe
fails when it gets to the door area.

Is there anyway to make FBP log what's going on so I
can delete the offending file? Right now I just have
to have all descriptions blank to make it continue
through the rest of the areas.

I had a similar problem fbn.exe. Couldn't work it out. I switched to fb.exe (16
bit version) and it processed all areas ok.

===========================================================================
rem ; ``fbn'' causes a Dr. Watson Exception access violation in NT 4:
rem ; Reading (72)The instruction at 77f88d33 referenced memory at 7864692e
rem ; The memory could not be read from
rem fbn -a
fb -a -p%maximus% ===========================================================================


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

NOTE: IceEdit 2.35 M16251

I had a similar problem fbn.exe. Couldn't work it out. I switched
to fb.exe (16 bit version) and it processed all areas ok.

Interesting. I will give it a shot. Will let you know!

Shawn

... An honest politician is one who, when bought, stays bought.

---
* Origin: Tiny's BBS t1ny.kicks-ass.org Back/2! (1:229/452)

NOTE: IceEdit 2.35 M16251

I had a similar problem fbn.exe. Couldn't work it out. I switched
to fb.exe (16 bit version) and it processed all areas ok.

It processed all areas but only did a set number, but I was able to figure out the offending files this way!

All working correctly again, thanks for the idea!

Shawn

... A countryman between two lawyers is like a fish between two cats.

---
* Origin: Tiny's BBS t1ny.kicks-ass.org Back/2! (1:229/452)

NOTE: IceEdit 2.35 M16251

I had a similar problem fbn.exe. Couldn't work it out. I switched
to fb.exe (16 bit version) and it processed all areas ok.

It processed all areas but only did a set number, but
I was able to figure out the offending files this way!

All working correctly again, thanks for the idea!

Hmm. Would probably be a good idea to add some debugging functionality into the
fb utility. I'll add that to the wishlist.

What was the problem with the file / description that caused fb to fail ?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hmm. Would probably be a good idea to add some debugging
functionality into the fb utility. I'll add that to the wishlist.

Great.

What was the problem with the file / description that caused fb to fail ?

Honestly I'm not sure. I'm thinking it was either too long or had too much high ascii in it. There were 6 all told in there, and I just kept manually editing them down to the bare basics until it finished.

If it would help I can certainly post or email you a couple of the offending file_id.diz's?

Shawn

... Golf is a walk, spoiled.

---
* Origin: Tiny's BBS t1ny.kicks-ass.org Back/2! (1:229/452)

What was the problem with the file / description
that caused fb to fail ?

Honestly I'm not sure. I'm thinking it was either
too long or had too much high ascii in it. There were
6 all told in there, and I just kept manually editing
them down to the bare basics until it finished.

If it would help I can certainly post or email you a
couple of the offending file_id.diz's?

Can I download those files (containing the file_id.diz's) somewhere ?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Can I download those files (containing the file_id.diz's) somewhere ?

Yep. From http://t1ny.kicks-ass.org:9080/files in the doors section grab "abyss010.zip" and "apok.zip". Those are the first two that fb got stuck on, there are others I can hunt down again if you want them.

(You can also telnet to t1ny.kicks-ass.org for the BBS interface if you would
rather download that way).

Shawn

... Every living thing wants to survive. Spock, stardate 4731.3.

---
* Origin: Tiny's BBS t1ny.kicks-ass.org Back/2! (1:229/452)

Can I download those files (containing the file_id.diz's) somewhere ?

Yep. From http://t1ny.kicks-ass.org:9080/files in
the doors section grab "abyss010.zip" and "apok.zip".
Those are the first two that fb got stuck on, there are
others I can hunt down again if you want them.

I reached the website, but couldn't download the file. Internet Explorer timedout for some reason.

(You can also telnet to t1ny.kicks-ass.org for the
BBS interface if you would rather download that way).

I manually imported the file_id.diz's into my files.bbs using Gvim (a text editor) and compiled all areas ok with the 16 bit fb. But 32 bit fb (fbn) still
died on area 72 for some strange reason ...

...
...
...
Processing M:\base\Filebase\ftp\simtel.net\arcutils\ 0197 - Sorting - Done!
Reading (72)The instruction at 7c9012b4 referenced memory at 7362625c
The memory could not be read from^C
C:\Program Files\CA\BrightStor ARCserve Backup>

<shrug>.

Maybe I should try reproducing your error by importing via MFM but I'm too lazy.

Btw do you have Arrowbridge I working ?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hello Mvan,

On 02/Jun/07 at 00:13 you wrote:

I reached the website, but couldn't download the file. Internet
Explorer timedout for some reason.

Hrmmm.

Maybe I should try reproducing your error by importing via MFM but
I'm too lazy.

Laugh know that feeling well. Are you able to import file_id.diz from MFM? I can't find the button to do that one. :)

Btw do you have Arrowbridge I working ?

No, I have Arrowbridge II working though... Might be the same trick, I had to
use a dorinfox.def instead of door.sys or else nothing is displayed to the remote user.

Just need to change your dorinfo.mec file to create the dorinfox.def's as well since AB2 refuses to accept dorinfo1.def from node2.

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

Hello Mvan,

On 02/Jun/07 at 00:13 you wrote:

I reached the website, but couldn't download the file. Internet
Explorer timedout for some reason.

Hrmmm.

Maybe I should try reproducing your error by importing via MFM but
I'm too lazy.

Laugh know that feeling well. Are you able to import
file_id.diz from MFM? I can't find the button to do
that one. :)

Did MFM ever import file_id.diz's ? ... I forgot ...

Btw do you have Arrowbridge I working ?

No, I have Arrowbridge II working though... Might be
the same trick, I had to use a dorinfox.def instead of
door.sys or else nothing is displayed to the remote user.

I had the same problem with door.sys with AB-I. Probably because either Maximus
generates an incompatible and/or non-standard compliant door.sys or the AB source code for retrieving node number from a standard door.sys dropfile is wrong.

Just need to change your dorinfo.mec file to create
the dorinfox.def's as well since AB2 refuses to accept
dorinfo1.def from node2.

Probably because it's looking for dorinfo2.def for node 2 etc. Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming AB-II works similarly.

Example ab1v140.bat: =======================================================================
@echo off

rem ;
rem ; switch to game directory
rem ;

%bbsdrive%:
cd %gamesroot%\ab1v140

rem ;
rem ; copy dropfile
rem ;

rem ; door.sys doesn't work ... using dorinfo1.def instead
rem copy %max%\door.sys .
copy %max%\dorinfo1.def .\dorinfo%1.def

rem ;
rem ; run command
rem ;

ABRIDGE.EXE /node%1 /p%gamesroot%\ab1v140 =======================================================================

Example menus.Ctl: ======================================================================= xtern_dos m:\games\ab1v140\ab1v140.bat_%k normal "Arrowbridge I" =======================================================================

Apparently people adopted the numeral in dorinfo#.def to be a node designator when it was never meant to be. It's probably a "dorinfo" dropfile specification
version number.

I can't get my AB-I character past Level 8 and am spewing.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hello Mvan,

On 05/Jun/07 at 05:07 you wrote:

I reached the website, but couldn't download the file. Internet
Explorer timedout for some reason.

Hrmmm.

I fixed that. Took me a while to figure out it was the FTP / NAT badness. Just changed it to use HTTP to send files now.

file_id.diz from MFM? I can't find the button to do
that one. :)

Did MFM ever import file_id.diz's ? ... I forgot ...

Okay then I'm not out to lunch. :) I just mis-read what you said. I've almost got an updated MFM with file_id.diz importing working, just being held up by time removing the fossil / door code to MFM which is causing a giant headache in the OS/2, Win32 port.
Besides does anyone run it as a door anymore?

compliant door.sys or the AB source code for retrieving node number
from a standard door.sys dropfile is wrong.

I'm going to blame the Ab source code because I have around 30 other doors using door.sys without a problem. :)

Probably because it's looking for dorinfo2.def for node 2 etc.
Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming
AB-II works similarly.

Exactly.

copy %max%\dorinfo1.def .\dorinfo%1.def

I never thought of doing it that way, I changed the dorinfo.mec file with a bunch of [if task] lines. :) Your way is much easier.

Apparently people adopted the numeral in dorinfo#.def to be a node designator when it was never meant to be. It's probably a "dorinfo" dropfile specification version number.

I wonder if that's what happened? Makes sense.

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

file_id.diz from MFM? I can't find the button to do
that one. :)

Did MFM ever import file_id.diz's ? ... I forgot ...

Okay then I'm not out to lunch. :) I just mis-read
what you said. I've almost got an updated MFM with
file_id.diz importing working, just being held up by
time removing the fossil / door code to MFM which is
causing a giant headache in the OS/2, Win32 port.

Man I just use the Hurl menu option.

Besides does anyone run it as a door anymore?

Not me. I'll set it up one day for kicks, just to remember what it does. I never really used it.

compliant door.sys or the AB source code for retrieving node number
from a standard door.sys dropfile is wrong.

I'm going to blame the Ab source code because I have
around 30 other doors using door.sys without a problem.
:)

That's what I thought too :)

Probably because it's looking for dorinfo2.def for node 2 etc.
Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming
AB-II works similarly.

Exactly.

copy %max%\dorinfo1.def .\dorinfo%1.def

I never thought of doing it that way, I changed the
dorinfo.mec file with a bunch of [if task] lines. :)

Me too, but for a different reason:

========================================================================== [iftask]1 [goto run_game]
...
...
...
[iftask]9 [goto run_game]

[lightred]Arrowbridge will only run on nodes 1 - 9 ! [dim](You are on node [node_num])
[exit]

[/run_game]
[link]misc\LEAVING
[xtern_dos]m:\games\ab1v140\ab1v140.bat %k ==========================================================================

Apparently people adopted the numeral in dorinfo#.def to be a node designator when it was never meant to be. It's probably a "dorinfo" dropfile specification version number.

I wonder if that's what happened? Makes sense.

I dunno. I just adapt to whatever works. I stopped questioning it a long time ago :)


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Okay then I'm not out to lunch. :) I just mis-read
what you said. I've almost got an updated MFM with
file_id.diz importing working, just being held up by
time removing the fossil / door code to MFM which is
causing a giant headache in the OS/2, Win32 port.

MvanL> Man I just use the Hurl menu option.

what has that to do with removing fossil and door library code from the package
in question? hurl is used to move a file from one location to another along with its description... that has nothing to do with the original question and discussion about MFM importing file_id.diz files...

[Arrowbridge I]

MvanL>> Probably because it's looking for dorinfo2.def for node 2 etc.
MvanL>> Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming
MLvan>> AB-II works similarly.

Exactly.

MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def

that is exactly how one does it with a system that doesn't create dorinfo2-9 files... now, what does one do when they are running 10 or more nodes? the dorinfox.def standard wasn't thought thru very well... i've seen implementation
that use hex and as such can support up to 16 nodes... i've also seen implementations that support base36 which is also limiting on a large multinode
system... then, there're those that start dropping letters to make room for numbers...

ie: dorinfo1.def
dorinf22.def
dorin134.def

like i say, not very well thought out... but it is way way way too late to do anything about it now, too... i tried some 15 years back but all anyone wanted to do then was spout the existing standard and do nothing about fixing or enhancing it...

[trim]

MvanL>> Apparently people adopted the numeral in dorinfo#.def to
MvanL>> be a node designator when it was never meant to be. It's
MLvan>> probably a "dorinfo" dropfile specification version number.

hunh? you can provide documentation to this? i'd like to read it because nothing like it was ever presented or found in all my research years ago... everything i found showed that the number _was_ the node number... some bbs systems got around the 9 node limitation by creating dorinfo1.def for all nodes, though... and that's no real problem if the door can look in a directory
other than its own for the drop file...

ie: somedoor c:\bbs\n1

where c:\bbs\n1 is where the dropfile, whatever is being used, is located... c:\bbs\n42 for node 42... no copying or overwritting and no possibility of things going wonky if two users enter the door at the same time...

)\/(ark


* Origin: (1:3634/12)

Hello Mvan,

On 08/Jun/07 at 07:34 you wrote:

Man I just use the Hurl menu option.

Laugh, which is what I'm using it for too! ;) I just figured if the source is there and I have time, I might as well try to update it enough to maybe offer people something that does everything.

Besides does anyone run it as a door anymore?

Not me. I'll set it up one day for kicks, just to remember what it
does. I never really used it.

I think I'm just going to continue stripping the fossil code out of it then. :)

dorinfo.mec file with a bunch of [if task] lines. :)

Me too, but for a different reason:
[lightred]Arrowbridge will only run on nodes 1 - 9 ! [dim](You are
on node [node_num]) [exit]

Ahh! I only run 3 nodes now so didn't even bother about that. :) If I need more then 9 nodes in this day and age I won't mind changing everything again. :)

I dunno. I just adapt to whatever works. I stopped questioning it a
long time ago :)

Laugh that's the way to do it for sure.

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

MvanL> Man I just use the Hurl menu option.

what has that to do with removing fossil and door
library code from the package in question? hurl is used
to move a file from one location to another along with
its description... that has nothing to do with the
original question and discussion about MFM importing file_id.diz files...

Hurl has everything to do with not removing fossil, library code and importing file_id.diz's with the package in the original question and discussion.

MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def

that is exactly how one does it with a system that
doesn't create dorinfo2-9 files... now, what does one
do when they are running 10 or more nodes? the

Pass the node as an argument to the door. If the door doesn't support such execution then use an alternate dropfile.

dorinfox.def standard wasn't thought thru very well...

People assuming that "x" is a node designator would be uncomfortable with their
understanding of dorinfo1.def.

i've seen implementation that use hex and as such can
support up to 16 nodes... i've also seen
implementations that support base36 which is also
limiting on a large multinode system... then, there're
those that start dropping letters to make room for numbers...

ie: dorinfo1.def
dorinf22.def
dorin134.def

Which is all pointless unless the door is programmed to read the most recent created *.def file or accept a node number as a command line option.

A "/node=65535" sounds pretty limitless to me.

like i say, not very well thought out... but it is way
way way too late to do anything about it now, too... i
tried some 15 years back but all anyone wanted to do
then was spout the existing standard and do nothing
about fixing or enhancing it...

... assuming it needed fixing or enhancing. That's what alternate dropfiles were for eg. door.sys.

Did you ever think dorinfo1.def was made for Maximus/QBBS/RBBS, and that doors written for these systems were meant to follow a standard method of execution ie. support a /n# or /node= et al. ? and/or interface with their respective BBS's in a certain way ... The same way(s) exitinfo works for RA and forces all
RA util authors to adhere to its ideologies, and prevents other BBS's from using exitinfo-specific doors ?

[trim]

MvanL>> Apparently people adopted the numeral in dorinfo#.def to
MvanL>> be a node designator when it was never meant to be. It's
MLvan>> probably a "dorinfo" dropfile specification version number.

hunh? you can provide documentation to this? i'd like
to read it because nothing like it was ever presented
or found in all my research years ago... everything i
found showed that the number _was_ the node number...

Because that became the most popular train of thought.

It is documented somewhere - some BBS/door author(s) made a complaint.

some bbs systems got around the 9 node limitation by
creating dorinfo1.def for all nodes, though... and
that's no real problem if the door can look in a
directory other than its own for the drop file...

ie: somedoor c:\bbs\n1

where c:\bbs\n1 is where the dropfile, whatever is
being used, is located... c:\bbs\n42 for node 42... no
copying or overwritting and no possibility of things
going wonky if two users enter the door at the same time...

My argument would be people started writing and using TCP/IP and multithreaded daemons and computer clusters and invented the I-n-t-e-r-n-e-t.

And that's why those large multinode BBS's are extinct and any node/dropfile conflict issues are nowadays virtually impossible.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Man I just use the Hurl menu option.

Laugh, which is what I'm using it for too! ;) I just
figured if the source is there and I have time, I might
as well try to update it enough to maybe offer people
something that does everything.

Is it C/C++ ?


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> Man I just use the Hurl menu option.

what has that to do with removing fossil and door
library code from the package in question? hurl is used
to move a file from one location to another along with
its description... that has nothing to do with the
original question and discussion about MFM importing
file_id.diz files...

MvanL> Hurl has everything to do with not removing fossil, library
MvanL> code and importing file_id.diz's with the package in the
MvanL> original question and discussion.

i fail to see how... one is programming... the other is naught but file area maint... hurl is for moving (hurling) files from one file area to another... unless the term "hurl" has been bastardized like so many others :(

)\/(ark


* Origin: (1:3634/12)

dorinfox.def standard wasn't thought thru very well...

MvanL> People assuming that "x" is a node designator would be
MvanL> uncomfortable with their understanding of dorinfo1.def.

why? dorinfox.def doesn't carry the node number internally...

)\/(ark


* Origin: (1:3634/12)

i've seen implementation that use hex and as such can
support up to 16 nodes... i've also seen
implementations that support base36 which is also
limiting on a large multinode system... then, there're
those that start dropping letters to make room for numbers...

ie: dorinfo1.def
dorinf22.def
dorin134.def

MvanL> Which is all pointless unless the door is programmed to read
MvanL> the most recent created *.def file or accept a node number as
MvanL> a command line option.

haha... good thing you're not a real programmer, then O:)

what's wrong with passing the dropfile name on the command line and letting the
door parse that filename to determine the node number? believe it or not, it works for many doors out there ;)

MvanL> A "/node=65535" sounds pretty limitless to me.

furrfu, damn good thing you're not a real programmer ;) it is arbitrary limits like that that have caused all kinds of problems over the years...

for instance...
1. some popular offline mail readers have a 200 =line= limit...

2. some FTN mail tossers can't process FTN messages larger than
16K... fewer can handle 32K... what's the problem? the specs
state that the message body of a packed message is
unbounded... that means that you read until you hit the next
null character not just read 16K... that's laziness, amoung
other things ;)

3. [damn, i had another well known one and lost it :( ]

)\/(ark


* Origin: (1:3634/12)

like i say, not very well thought out... but it is way
way way too late to do anything about it now, too... i
tried some 15 years back but all anyone wanted to do
then was spout the existing standard and do nothing
about fixing or enhancing it...

MvanL> ... assuming it needed fixing or enhancing. That's what
MvanL> alternate dropfiles were for eg. door.sys.

sorry... not... alternate dropfiles were created because info not available in dorinfox.def was needed... besides, door.sys evidently has problems, too... if it didn't door32.sys wouldn't have been created, eh? :)

)\/(ark


* Origin: (1:3634/12)

some bbs systems got around the 9 node limitation by
creating dorinfo1.def for all nodes, though... and
that's no real problem if the door can look in a
directory other than its own for the drop file...

ie: somedoor c:\bbs\n1

where c:\bbs\n1 is where the dropfile, whatever is
being used, is located... c:\bbs\n42 for node 42... no
copying or overwritting and no possibility of things
going wonky if two users enter the door at the same time...

MvanL> My argument would be people started writing and using TCP/IP
MvanL> and multithreaded daemons and computer clusters and invented
MvanL> the I-n-t-e-r-n-e-t.

haha... that's not an argument... that's a diversion so that one can exit the building and not have to face the discussion at hand ;)

MvanL> And that's why those large multinode BBS's are extinct and any
MvanL> node/dropfile conflict issues are nowadays virtually
MvanL> impossible.

i disagree... most of them have simply changed faces... many BBS systems are now ISPs... a lot of BBS systems have also moved to forum style interfaces... i
don't see any of the goo old BBS doors available in any new formats, though...

)\/(ark


* Origin: (1:3634/12)

Hello Mvan,

On 09/Jun/07 at 12:34 you wrote:

figured if the source is there and I have time, I might
something that does everything.

Is it C/C++ ?

No pascal. If it was C/C++ I wouldn't have a clue, looks like an alien language to me.

If your a C programmer any chance I could get you to download the Jamnntpd with SMAPI support and compile me an os/2 version of that bad boy?

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

Hello mark,

On 09/Jun/07 at 18:01 you wrote:

style interfaces... i don't see any of the goo old BBS doors available
in any new formats, though...

I keep trying. :) I've got CGI versions of the Wall and Hangman, but they are very simple doors. Also programming for the web is a totally
different animal (As I'm sure your aware) and just not as easy as CRT. :)

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

figured if the source is there and I have time, I might
something that does everything.

Is it C/C++ ?

No pascal. If it was C/C++ I wouldn't have a clue, looks
like an alien language to me.

If your a C programmer any chance I could get you to
download the Jamnntpd with SMAPI support and compile me an
os/2 version of that bad boy?

if it is nothing more than a compile, i might be able to do that... well, if you're on OS/2 and have the EMX runtime, that is ;)

)\/(ark


* Origin: (1:3634/12)

MvanL> Hurl has everything to do with not removing fossil, library code and MvanL> importing file_id.diz's with the package in the original question MvanL> and discussion.

i fail to see how... one is programming... the other is naught but file area

That's due to your myopic interpretation of the discussion you replied to.

maint... hurl is for moving (hurling) files from one file area to

And is a file / filearea maintenance tool.

another... > unless the term "hurl" has been bastardized like so many others :(

Who cares. English words are subject to democratic acceptance and semantic evolution.

MvanL> People assuming that "x" is a node designator would be uncomfortable
MvanL> with their understanding of dorinfo1.def.

why? dorinfox.def doesn't carry the node number internally...

And that's why you're confused and unhappy.

I understand your failure to accept responsibility for a misguided belief is causing you pain, frustration and dissatisfaction and you want other people (me) to offer some form of compensation.

The fact is dorinfo1.def dropfiles do not provide node numbers. They never have, and never will. It's not in its specification, which remains unchanged to this day. And you're disputing it - that's why it's a problem for you.

Your values and beliefs are not aligned with what the external environment is communicating to you, and naturally you expect to seek remedies to rectify
the emotional imbalance you feel with respect to this matter.

Well, there's no remedy.

ie: dorinfo1.def dorinf22.def dorin134.def

MvanL> Which is all pointless unless the door is programmed to read the mos
MvanL> recent created *.def file or accept a node number as a command
MvanL> line option.

haha... good thing you're not a real programmer, then O:)

RA should drop support for exitinfo and strictly adhere to door.sys standards then, because their programmers couldn't fathom the limiting issues with
their chosen implementation.

what's wrong with passing the dropfile name on the command line and letting door parse that filename to determine the node number? believe it or not, it works for many doors out there ;)

What's wrong with passing the node number as an option to the door ? hence rendering node number dropfile naming conventions irrelevant. Believe it or not it works for many doors out there.

MvanL> A "/node=65535" sounds pretty limitless to me.

furrfu, damn good thing you're not a real programmer ;) it is arbitrary
limi > like that that have caused all kinds of problems over the years...

It's not an arbitrary limit. It's an example command line option.

for instance... 1. some popular offline mail readers have a 200
=line= limit...

2. some FTN mail tossers can't process FTN messages larger than
16K... fewer can handle 32K... what's the problem? the specs state
that the message body of a packed message is unbounded...
that means that you read until you hit the next null character
not just read 16K... that's laziness, amoung other things ;)

Which are all issues for the relevant applications and users of those applications, and are non existent problems for me.

Firstly, I definitely would seriously reconsider using any mail readers limited to a crappy 200 line message.

Secondly because Squish can be configured to split large packet sizes I have no problem sending or receiving messages for any practical purpose.

MvanL> ... assuming it needed fixing or enhancing. That's what alternate
MvanL> dropfiles were for eg. door.sys.

sorry... not... alternate dropfiles were created because info not available dorinfox.def was needed... besides, door.sys evidently has problems, too...

What part of "That's what alternate dropfiles were for" didn't you understand ?

it didn't door32.sys wouldn't have been created, eh? :)

That's because people prefer to store connection details like socket handles in dropfiles rather than passed as command line options.

MvanL> My argument would be people started writing and using TCP/IP and
MvanL> multithreaded daemons and computer clusters and invented the
MvanL> I-n-t-e-r-n-e-t.

haha... that's not an argument... that's a diversion so that one can exit th building and not have to face the discussion at hand ;)

I'll reiterate my point which is - The issues you've presented regarding "possible" multinode dropfile conflicts are extinct.

MvanL> And that's why those large multinode BBS's are extinct and any
MvanL> node/dropfile conflict issues are nowadays virtually impossible.

i disagree... most of them have simply changed faces... many BBS systems are now ISPs... a lot of BBS systems have also moved to forum style interfaces.. don't see any of the goo old BBS doors available in any new formats, though.

I disagree. They haven't merely "changed faces". They adopted entirely new system processes, methodologies and infrustructure. They stopped using BBS's to provide the (ISP) services you're describing a long time ago. Such decisions nowadays are ludicrous except for the BBS hobbyist.

figured if the source is there and I have time, I might something
that does everything. Is it C/C++ ?

No pascal. If it was C/C++ I wouldn't have a clue, looks like an alien language to me.

Bleh. Not for me then :)

If your a C programmer any chance I could get you to download
the Jamnntpd with SMAPI support and compile me an os/2 version
of that bad boy?

if it is nothing more than a compile, i might be able to do that... well, if you're on OS/2 and have the EMX runtime, that is ;)

Yeah. What Mark Lewis said.

You could also try the Open Watcom compiler, which cross compiles OS/2 binaries.

Hello mark,

On 09/Jun/07 at 23:59 you wrote:

if it is nothing more than a compile, i might be able to do that...
well, if you're on OS/2 and have the EMX runtime, that is ;)

I am on OS/2 and do have the EMX runtime. :) I just can't for the life
of me figure out how to compile anything. :) There's a makefile.os2 in there and it should be straight forward. (Just not for me)


Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

Hello Hostile,

On 10/Jun/07 at 03:33 you wrote:

No pascal. If it was C/C++ I wouldn't have a clue, looks like an alien language to me.

Bleh. Not for me then :)

Laugh your one of those alien's eh? ;) My neighbour is a teacher at a local community college and has all these textbooks on learning to program C++. He keeps offering them to me, but it just doesn't look anything like that I expect
it to. (Can you tell I'm just stubern?)


Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

Hello Hostile,

On 10/Jun/07 at 03:35 you wrote:

You could also try the Open Watcom compiler, which cross compiles OS/2 binaries.

I actually installed Open Watcom to try this, but I think the makefile / code
is desgined for GCC, it just failed horibily, but again I don't know what I'm doing. :)

The Smapi version of Jamnntpd is available at www.billingware.org and does have an os/2 makefile in it.

Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

MvanL> Hurl has everything to do with not removing fossil,
MvanL> library code and importing file_id.diz's with the
MvanL> package in the original question and discussion.

i fail to see how... one is programming... the other is
naught but file area [...]

That's due to your myopic interpretation of the discussion you
replied to.

wrong... that is due to the fact that i can seperate intertwined subjects from each other and take each at its face value ;)

so, why'd you change your name to "hostile"? is it more fitting??

maint... hurl is for moving (hurling) files from one file area to

And is a file / filearea maintenance tool.

is that not what i said? a tool to hurl files from here to there??

another... > unless the term "hurl" has been bastardized like
so many others :(

Who cares.

a lot of folk, obviously... but we already knwo that doesn't include you per your own writtings of selfishness based on your childhood :(

English words are subject to democratic acceptance and
semantic evolution.

that's copout attitude...

)\/(ark


* Origin: (1:3634/12)

MvanL> People assuming that "x" is a node designator
MvanL> would be uncomfortable with their understanding
MvanL> of dorinfo1.def.

why? dorinfox.def doesn't carry the node number internally...

And that's why you're confused and unhappy.

yeah? what gives you that majorly erroneous idea? there's no imperical evidence
pointing to it, is there??

)\/(ark


* Origin: (1:3634/12)

ie: dorinfo1.def dorinf22.def dorin134.def

MvanL> Which is all pointless unless the door is
MvanL> programmed to read the most recent created *.def
MvanL> file or accept a node number as a command line
MvanL> option.

haha... good thing you're not a real programmer, then O:)

RA should drop support for exitinfo and strictly adhere to
door.sys standards then, because their programmers couldn't
fathom the limiting issues with their chosen implementation.

you obviously don't have a clue what information is contained within the exitinfo.bbs file, then... for one thing, tell me if door.sys can carry the info on what message areas a user has selected to join... never mind, as you can't tell me that... truth be known, exitinfo.bbs carries all bbs config information as it relates to the currently logged on user...

what's wrong with passing the dropfile name on the command
line and letting door parse that filename to determine the
node number? believe it or not, it works for many doors out
there ;)

What's wrong with passing the node number as an option to
the door ? hence rendering node number dropfile naming
conventions irrelevant. Believe it or not it works for
many doors out there.

duh? i think i've been doing this a few more years than you have, Mvan... at least as long as you are years old, thankyouverymuch...

MvanL> A "/node=65535" sounds pretty limitless to me.

furrfu, damn good thing you're not a real programmer ;) it
is arbitrary limit like that that have caused all kinds of
problems over the years...

It's not an arbitrary limit. It's an example command line
option.

it doesn't read that way... apologies if i misread your mind as you didn't say that in that manner...

for instance... 1. some popular offline mail readers have a 200
=line= limit...

2. some FTN mail tossers can't process FTN messages larger than
16K... fewer can handle 32K... what's the problem? the specs state
that the message body of a packed message is unbounded...
that means that you read until you hit the next null character
not just read 16K... that's laziness, amoung other things ;)

Which are all issues for the relevant applications and users
of those applications, and are non existent problems for me.

we're not talking about just you... there are others in the world doing this stuff ;)

Firstly, I definitely would seriously reconsider using any
mail readers limited to a crappy 200 line message.

then i guess you don't use bluewave or any other similar offline mail readers...

Secondly because Squish can be configured to split large
packet sizes I have no problem sending or receiving messages
for any practical purpose.

that's all well and good... too bad the split proposal that squish and others follow is directed at the wrong side of the "too large a message" problem :(

)\/(ark


* Origin: (1:3634/12)

You could also try the Open Watcom compiler, which
cross compiles OS/2
binaries.

I actually installed Open Watcom to try this, but I
think the makefile / code is desgined for GCC, it just
failed horibily, but again I don't know what I'm doing.
:)

The Maximus / Squish source code was set up for the commercial watcom compiler.
The port to Linux (the current source forge branch) uses the normal make file for GCC. There hasn't been any work on getting things cleaned up and unified....

My apologies if I'm taking comments out of context. I am trying to catch up on
a backlog of echomail messages.

Take care....
Bob Jones, 1:343/41

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hello Bob,

On 10/Jun/07 at 13:57 you wrote:

My apologies if I'm taking comments out of context. I am trying to
catch up on a backlog of echomail messages.

No problem Bob, we were discussing something offtopic. :) The Jamnntpd
SMAPI version for os/2.


Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

Hello Hostile,

On 10/Jun/07 at 03:33 you wrote:

No pascal. If it was C/C++ I wouldn't have a clue, looks like an alien language to me.

Bleh. Not for me then :)

Laugh your one of those alien's eh? ;) My neighbour

If your home planet is Earth then Pascal programmers are the aliens :)

is a teacher at a local community college and has all
these textbooks on learning to program C++. He keeps
offering them to me, but it just doesn't look anything
like that I expect it to. (Can you tell I'm just stubern?)

Yep. Stubborn are people who vehemently (and annoyingly) advocate DOS and/or OS2 and Pascal. I can tell they're trapped in a time warp and are invariably in
their mid 40s. Time is running out for them. MUAhaha <evil laugh>.

People don't use Pascal for any serious programming, and before a debate about that happens I will ask how many kernels, Operating Systems, low level device drivers and embedded devices are written in Pascal compared to C/C++ :)

Pascal is suited as a teaching language, and even then I wouldn't recommend it.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

i fail to see how... one is programming... the other is
naught but file area [...]

That's due to your myopic interpretation of the discussion you
replied to.

wrong... that is due to the fact that i can seperate
intertwined subjects from each other and take each at
its face value ;)

And make a fuss of it.

so, why'd you change your name to "hostile"? is it more fitting??

That's the nick on Vertrauen.

maint... hurl is for moving (hurling) files from one file area to

And is a file / filearea maintenance tool.

is that not what i said? a tool to hurl files from here to there??

Which is pertinent to the thread you replied to.

another... > unless the term "hurl" has been bastardized like
so many others :(

Who cares.

a lot of folk, obviously... but we already knwo that
doesn't include you per your own writtings of
selfishness based on your childhood :(

Selfishness is good.

English words are subject to democratic acceptance and
semantic evolution.

that's copout attitude...

Mainstream works for me.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> People assuming that "x" is a node designator
MvanL> would be uncomfortable with their understanding
MvanL> of dorinfo1.def.

why? dorinfox.def doesn't carry the node number internally...

And that's why you're confused and unhappy.

yeah? what gives you that majorly erroneous idea?

Your futile unending tenacious debate of facts.

there's no imperical evidence pointing to it, is there??

Imperical evidence eh ... let's see ... why don't you tell us all about it.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

you obviously don't have a clue what information is
contained within the exitinfo.bbs file, then... for one
thing, tell me if door.sys can carry the info on what
message areas a user has selected to join... never
mind, as you can't tell me that... truth be known,

Heh. The keyword is "can" - and surprise door.sys can.

exitinfo.bbs carries all bbs config information as it
relates to the currently logged on user...

So why should dorinfo1.def carry any more details. It satisfied the requirement
of whomever invented it.

If people deviate from the specification and adopt different methods for using dorinfo1.def that's their perogative, which doesn't change the fact that the number in the dorinfo1.def dropfile was never meant to designate a node number.

What's wrong with passing the node number as an option to
the door ? hence rendering node number dropfile naming
conventions irrelevant. Believe it or not it works for
many doors out there.

duh? i think i've been doing this a few more years than
you have, Mvan... at least as long as you are years
old, thankyouverymuch...

Oooo wow I'm scared.

MvanL> A "/node=65535" sounds pretty limitless to me.

furrfu, damn good thing you're not a real programmer ;) it
is arbitrary limit like that that have caused all kinds of
problems over the years...

It's not an arbitrary limit. It's an example command line
option.

it doesn't read that way... apologies if i misread your
mind as you didn't say that in that manner...

Does "65535" LOOK like an arbitrary number to you ?

for instance... 1. some popular offline mail readers have a 200
=line= limit...

2. some FTN mail tossers can't process FTN messages larger than
16K... fewer can handle 32K... what's the problem? the specs state
that the message body of a packed message is unbounded...
that means that you read until you hit the next null character
not just read 16K... that's laziness, amoung other things ;)

Which are all issues for the relevant applications and users
of those applications, and are non existent problems for me.

we're not talking about just you... there are others in
the world doing this stuff ;)

And they voluntarily work within any existing or implied constraints. But ultimately it's not my problem.

Software limitations eg. integer, character limits etc. may be the result of conscious decisions to preserve valuable runtime resources. Y2k compatibility is an example.

Even today's web forms, or even databases ask the admins/programmers to define maximum line length and tablespace usage limits.

These are not "arbitrary" decisions due to lack of foresight as you love to accuse, but are based on what is warranted and/or required at the time of implementation, and which may often remain up to the descretion of those implementors.

Firstly, I definitely would seriously reconsider using any
mail readers limited to a crappy 200 line message.

then i guess you don't use bluewave or any other
similar offline mail readers...

I use Bluewave OLR. I've never had a problem with it. Heh.

Secondly because Squish can be configured to split large
packet sizes I have no problem sending or receiving messages
for any practical purpose.

that's all well and good... too bad the split proposal
that squish and others follow is directed at the wrong
side of the "too large a message" problem :

It's a problem because of your point of view.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

No pascal. If it was C/C++ I wouldn't have a clue, looks
like an alien language to me.

Bleh. Not for me then :)

Laugh your one of those alien's eh? ;) My neighbour

If your home planet is Earth then Pascal programmers are

MvanL> the aliens :)

ROTFLMAO!! i guess C coders would think that even if the fact that PASCAL was invented first, by a year, eludes them ;)

[trim]

MvanL> People don't use Pascal for any serious programming, and
MvanL> before a debate about that happens I will ask how many
MvanL> kernels, Operating Systems, low level device drivers and
MvanL> embedded devices are written in Pascal compared to C/C++ :)

i guess you don't feel that systems with BASIC as their OS are real systems, either? ;) i'm aware of more than one mini, still in use today, that has BASIC as its core operating system and everything that runs on it is written in BASIC, as well ;)

MvanL> Pascal is suited as a teaching language, and even then I
MvanL> wouldn't recommend it.

somehow, i don't think we could expect any less of you ;)

)\/(ark


* Origin: (1:3634/12)

i fail to see how... one is programming... the other is
naught but file area [...]

That's due to your myopic interpretation of the discussion you
replied to.

wrong... that is due to the fact that i can seperate
intertwined subjects from each other and take each at
its face value ;)

MvanL> And make a fuss of it.

how so? i'm definitely not fussing, bitching, moaning, whining, or anything like that... you're the one who has come out on the attack for no reason whatsoever...

so, why'd you change your name to "hostile"? is it more fitting??

MvanL> That's the nick on Vertrauen.

great... i'll get a netmail off to that sysop and ask him to correct his configuration... i'm not aware of any echos in today's fidonet that allow handled or nicknames...

[trim]

another... unless the term "hurl" has been bastardized like
so many others :(

Who cares.

a lot of folk, obviously... but we already knwo that
doesn't include you per your own writtings of
selfishness based on your childhood :(

MvanL> Selfishness is good.

ya reap what ya sow... there's more than one selfish person that i've left standing by themselves because of their selfishness... what goes around comes around and strikes three times as hard... i've helped selfish folk and then had
them refuse to help me later... that put them in a predicament when they desperately needed some help and asked me for mine... one individual spent several months in jail waiting on his court date because i didn't loan him the $500US bond that would have allowed him to be free until that court date... that jail time lead to the loss of his job which also lead to the loss of his home and vehicle... go ahead... be selfish ;)

)\/(ark


* Origin: (1:3634/12)

MvanL> People assuming that "x" is a node designator
MvanL> would be uncomfortable with their understanding
MvanL> of dorinfo1.def.

why? dorinfox.def doesn't carry the node number internally...

And that's why you're confused and unhappy.

yeah? what gives you that majorly erroneous idea?

MvanL> Your futile unending tenacious debate of facts.

hahaha...

1. i _don't_ debate. that's your first error...

2. you've not been around these parts long enough to know
if it is unending or not. that's your second mistake...

there's no imperical evidence pointing to it, is there??

MvanL> Imperical evidence eh ... let's see ... why don't you
MvanL> tell us all about it.

i don't have to... you're so smart, you reinvent the wheel and do the research and spend the time like myself and others did years ago... one would think that
youth would rather learn from other's mistakes... oh yeah, i forgot... youth are born with all the answers... it isn't until their parents pass away that they realise how smart their parents really were and how ignorant they, themselves, still are...

)\/(ark


* Origin: (1:3634/12)

you obviously don't have a clue what information is
contained within the exitinfo.bbs file, then... for one
thing, tell me if door.sys can carry the info on what
message areas a user has selected to join... never
mind, as you can't tell me that... truth be known,

MvanL> Heh. The keyword is "can" - and surprise door.sys can.

yeah? for 65535 files areas and 65535 message areas? what format does this data
take? it isn't detailed in any of the specs i have...

exitinfo.bbs carries all bbs config information as it
relates to the currently logged on user...

MvanL> So why should dorinfo1.def carry any more details. It
MvanL> satisfied the requirement of whomever invented it.

i never said that dorinfox.def should carry more details... i said that it doesn't carry the node number internally... you extrapolated that on to something else...

MvanL> If people deviate from the specification and adopt different
MvanL> methods for using dorinfo1.def that's their perogative, which
MvanL> doesn't change the fact that the number in the dorinfo1.def
MvanL> dropfile was never meant to designate a node number.

you've still not provided the proof of this... i'm more than willing to look at
it once it is made available... i would hope that it is written by the original
author of the dorinfox.def specification ;)

What's wrong with passing the node number as an option to
the door ? hence rendering node number dropfile naming
conventions irrelevant. Believe it or not it works for
many doors out there.

duh? i think i've been doing this a few more years than
you have, Mvan... at least as long as you are years
old, thankyouverymuch...

MvanL> Oooo wow I'm scared.

ROTFL! no doubt...

MvanL> A "/node=65535" sounds pretty limitless to me.

furrfu, damn good thing you're not a real programmer ;) it
is arbitrary limit like that that have caused all kinds of
problems over the years...

It's not an arbitrary limit. It's an example command line
option.

it doesn't read that way... apologies if i misread your
mind as you didn't say that in that manner...

MvanL> Does "65535" LOOK like an arbitrary number to you ?

no... it is the largest value that a 16bit WORD can hold... that makes it the upper limit...

)\/(ark


* Origin: (1:3634/12)

Re: Another filearea question
By: mark lewis to Mvan Le on Mon Jun 11 2007 04:05 pm

so, why'd you change your name to "hostile"? is it more fitting??

MvanL> That's the nick on Vertrauen.

great... i'll get a netmail off to that sysop and ask him to correct his configuration... i'm not aware of any echos in today's fidonet that allow handled or nicknames...

No need, it's already fixed.

digital man (xbox-live: digitlman)

Snapple "Real Fact" #116:
The largest fish is the whale shark - it can be over 50 feet long and weigh 2 tons.
Norco, CA WX: 71.6°F, 55% humidity, 0 mph S wind, 0.00 inches rain/24hrs

so, why'd you change your name to "hostile"? is
it more fitting??

MvanL> That's the nick on Vertrauen.

great... i'll get a netmail off to that sysop and ask him
to correct his configuration... i'm not aware of any echos
in today's fidonet that allow handled or nicknames...

No need, it's already fixed.

thanks ;)

)\/(ark


* Origin: (1:3634/12)

ROTFLMAO!! i guess C coders would think that even if
the fact that PASCAL was invented first, by a year,
eludes them ;)

That makes Pascal even MORE outdated.

Are you schizophrenic ? because the train left a long time ago.

MvanL> People don't use Pascal for any serious programming, and
MvanL> before a debate about that happens I will ask how many
MvanL> kernels, Operating Systems, low level device drivers and
MvanL> embedded devices are written in Pascal compared to C/C++ :)

i guess you don't feel that systems with BASIC as their
OS are real systems, either? ;) i'm aware of more than
one mini, still in use today, that has BASIC as its
core operating system and everything that runs on it is
written in BASIC, as well ;)

OOooh ... An OS written in BASIC -- I understand the joke now !

Have you considered a career in comedy ?


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> Selfishness is good.

ya reap what ya sow... there's more than one selfish person that i've left standing by themselves because of their
selfishness... what goes around comes around and strikes three times as hard... i've helped selfish folk and then had them
refuse to help me later... that put them in a
predicament when they desperately needed some help and
asked me for mine... one individual spent several
months in jail waiting on his court date because i
didn't loan him the $500US bond that would have allowed
him to be free until that court date... that jail time
lead to the loss of his job which also lead to the loss
of his home and vehicle... go ahead... be selfish ;)

Someone spent months in jail because you refused to help when he/she desperately asked for it.

What goes around comes around.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> satisfied the requirement of whomever invented it.

i never said that dorinfox.def should carry more
details... i said that it doesn't carry the node number
internally... you extrapolated that on to something else...

The number in the dorinfo1.def dropfile file name was never meant to designate a node number -- not dorinfox.def, not dorinfo#.def, not "dorinfo dropfile" -- DORINFO1(ONE).DEF dropfile.

Do you understand the distinction between "The" dorinfo1.def dropfile and "those" dorinfo(x|#).def dropfiles ?

MvanL> If people deviate from the specification and adopt different
MvanL> methods for using dorinfo1.def that's their perogative, which
MvanL> doesn't change the fact that the number in the dorinfo1.def
MvanL> dropfile was never meant to designate a node number.

you've still not provided the proof of this... i'm more
than willing to look at it once it is made available...
i would hope that it is written by the original author
of the dorinfox.def specification ;)

http://en.wikipedia.org/wiki/Dropfile:

DORINFO1.DEF
RBBS-PC used this format exclusively. This file is 13 lines long.
The name of the dropfile never changed, even if it was used in
multi-node environments.

Ie. "The name of the dropfile (dorinfo1.def) _never_ changed, /even/ if it was used in multi-node environments.".

Additionally,

DORINFO#.DEF
Used by RemoteAccess, this allowed slightly more flexibility for one
to nine nodes. This is the exact same format as DORINFO1.DEF

Which is totally conclusive evidence that the RA mob initiated a dorinfo(x|#).def propaganda against dorinfo1.def which the BBS community later acquiesced towards.

You therefore are a victim of misinformation.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

ROTFLMAO!! i guess C coders would think that even if
the fact that PASCAL was invented first, by a year,
eludes them ;)

MvanL> That makes Pascal even MORE outdated.

as is C ;)

think about it...

)\/(ark


* Origin: (1:3634/12)

MvanL> Selfishness is good.

ya reap what ya sow... there's more than one selfish person
that i've left standing by themselves because of their
selfishness... what goes around comes around and strikes
three times as hard... i've helped selfish folk and then
had them refuse to help me later... that put them in a
predicament when they desperately needed some help and
asked me for mine... one individual spent several
months in jail waiting on his court date because i
didn't loan him the $500US bond that would have allowed
him to be free until that court date... that jail time
lead to the loss of his job which also lead to the loss
of his home and vehicle... go ahead... be selfish ;)

MvanL> Someone spent months in jail because you refused to help when
MvanL> he/she desperately asked for it.

lovely how you missed that i had already helped them and they refused to help me when i asked...

MvanL> What goes around comes around.

yup... your's is coming, too ;)

)\/(ark


* Origin: (1:3634/12)

MvanL> satisfied the requirement of whomever invented it.

i never said that dorinfox.def should carry more
details... i said that it doesn't carry the node number
internally... you extrapolated that on to something else...

MvanL> The number in the dorinfo1.def dropfile file name was never
MvanL> meant to designate a node number -- not dorinfox.def, not
MvanL> dorinfo#.def, not "dorinfo dropfile" -- DORINFO1(ONE).DEF
MvanL> dropfile.

MvanL> Do you understand the distinction between "The" dorinfo1.def
MvanL> dropfile and "those" dorinfo(x|#).def dropfiles ?

do you understand the meaning of "POST THE SPECS OR A LINK TO THEM"?

MvanL> If people deviate from the specification and adopt different
MvanL> methods for using dorinfo1.def that's their perogative, which
MvanL> doesn't change the fact that the number in the dorinfo1.def
MvanL> dropfile was never meant to designate a node number.

you've still not provided the proof of this... i'm more
than willing to look at it once it is made available...
i would hope that it is written by the original author
of the dorinfox.def specification ;)

MvanL> http://en.wikipedia.org/wiki/Dropfile:

oh, cool... i'll go fix that right now...

hint: don't take wikipedia as gospel...

[trim]

MvanL> Which is totally conclusive evidence that the RA mob initiated a
MvanL> dorinfo(x|#).def propaganda against dorinfo1.def which the BBS
MvanL> community later acquiesced towards.

no, it is not conclusive of that... QBBS was also using dorinfox.def at that time as were wildcat, pcboard, and many other mainstream bbs packages... besides, there's no cite for that information or a link to the specs those statements are drawn from...

MvanL> You therefore are a victim of misinformation.

in this instance, your mistake is in believing unproven and undocumented writtings that you read on wikipedia ;)

)\/(ark


* Origin: (1:3634/12)

mark lewis wrote in a message to Mvan Le:

in this instance, your mistake is in believing unproven and
undocumented writtings that you read on wikipedia ;)

If you take what you read on Wikipedia as gospel, you're an idiot, IMNSHO. That place is the world's biggest hangout for s*ithouse lawyers, if you know what I mean.

Later,
Sean

--- timEd/2 1.10.y2k+
* Origin: Outpost BBS - Douglasville, GA - 770-489-1561 (1:18/200)

Hello Mvan,

On 11/Jun/07 at 07:04 you wrote:

If your home planet is Earth then Pascal programmers are the aliens :)

Naaaa, Pascal looks closer to english. :)

Yep. Stubborn are people who vehemently (and annoyingly) advocate DOS and/or OS2 and Pascal. I can tell they're trapped in a time warp and
are invariably in their mid 40s. Time is running out for them. MUAhaha <evil laugh>.

I wouldn't say I vehemently advocate dos and/or os/2. I say use what works for you. I have Linux machines, an iMac, and the OS/2 machine which I prefer for the fidonet / BBS stuff. The one thing I don't have a dedicated machine for is Windows but I do have windows running in Parallels on the mac for work software.

As for programming, I was taught to program in highschool, the language was pascal, I'm not a serious programmer nor have any desire to be one. So the way
I look at it, for the one or two text mode programs I write in a year why should I learn anything new?

I'm also in my early 30's not 40's. (33 to be exact) Just started life a lot earlier then most people did.


Cheers,
Shawn

---
* Origin: Tiny's BBS Telnet://t1ny.kicks-ass.org Back/2! (1:229/452)

MvanL> What goes around comes around.

yup... your's is coming, too ;)

That's what you think.

You deserved what you got, and that other person deserved what s/he got.

You both deserved what you got.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

ROTFLMAO!! i guess C coders would think that even if
the fact that PASCAL was invented first, by a year,
eludes them ;)

MvanL> That makes Pascal even MORE outdated.

as is C ;)

Err no, C is continually in use for serious programming and will outlast Pascal.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> dropfile and "those" dorinfo(x|#).def dropfiles ?

do you understand the meaning of "POST THE SPECS OR A LINK TO THEM"?

If you want specs then look in the source code.

Maximus creates "dorinfo1".def for ALL NODES, and always has.

you've still not provided the proof of this... i'm more
than willing to look at it once it is made available...
i would hope that it is written by the original author
of the dorinfox.def specification ;)

MvanL> http://en.wikipedia.org/wiki/Dropfile:

oh, cool... i'll go fix that right now...

Haha you're not fixing anything, and merely demonstrating your pedantic childish need to challenge everything when the evidence is blatantly in your face and anybody actually remotely possessing an inkling of conducive attitude towards the -TRUTH- would see your stupid vain attempt to subvert a distinction
that exists between dorinfo1.def (which predates) and dorinfo(x|#).def.

hint: don't take wikipedia as gospel...

I have obliged your request for documentation.

MvanL> Which is totally conclusive evidence that the RA mob initiated a
MvanL> dorinfo(x|#).def propaganda against dorinfo1.def which the BBS
MvanL> community later acquiesced towards.

no, it is not conclusive of that... QBBS was also using
dorinfox.def at that time as were wildcat, pcboard, and
many other mainstream bbs packages... besides, there's
no cite for that information or a link to the specs
those statements are drawn from...

dorinfo1.def is created AS IS. For ANY node.

dorinfox.def is an adaptation of dorinfo1.def.

Same thing for dorin[#[#[#]]].def and any such variants.

MvanL> You therefore are a victim of misinformation.

in this instance, your mistake is in believing unproven
and undocumented writtings that you read on wikipedia

By the same token your mistakes derive from your poor deductive abilities.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

If you take what you read on Wikipedia as gospel,
you're an idiot, IMNSHO. That place is the world's
biggest hangout for s*ithouse lawyers, if you know what
I mean.

Ahem. Can you provide citations for those statements you've made to prove their
validity ?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Yep. Stubborn are people who vehemently (and
annoyingly) advocate DOS
and/or OS2 and Pascal. I can tell they're trapped in a time warp and
are invariably in their mid 40s. Time is running
out for them. MUAhaha
<evil laugh>.

I wouldn't say I vehemently advocate dos and/or os/2.

I never said nor implied that you did :)



--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Mvan Le wrote in a message to Shawn Highfield:

I wouldn't say I vehemently advocate dos and/or os/2.

I never said nor implied that you did :)

Okay. :) Well I'm going back to code MFM which seems to have started the dorinfo1.def discussion.

My stance on the dorinfo1.def subject is that I've always just gone with whatever the door required. Most of the time dorinfo1.def is used for all nodes. Of course the RA (and clone) specific doors did the dorinfox.def.

So.... I guess I don't care one way or the other since Maximus uses MECCA we can do whatever we have to to make the doors work!


Shawn 'Tiny' Highfield - http://t1ny.kicks-ass.org:9080

... War will cease when men refuse to fight.
---
* Origin: Tiny's BBS - telnet://t1ny.kicks-ass.org - Back/2! (1:229/452)

in this instance, your mistake is in believing unproven and
undocumented writtings that you read on wikipedia ;)

If you take what you read on Wikipedia as gospel, you're an idiot,
IMNSHO. That place is the world's biggest hangout for s*ithouse
lawyers, if you know what I mean.

yup... i'm just happy to have an editing account and can fix stuff when it noted to be incorrect... funny thing about that page he tossed my way... it is listed as abandoned and i think i know the guy who originally started it ;) ;) ;)

)\/(ark


* Origin: (1:3634/12)

MvanL> What goes around comes around.

yup... your's is coming, too ;)

MvanL> That's what you think.

that's what i know... without a doubt... life works that way and you are not immune to it no matter how much miney you have, how greedy you are, or even how
angry you get... it _will_ happen...

)\/(ark


* Origin: (1:3634/12)

ROTFLMAO!! i guess C coders would think that even if
the fact that PASCAL was invented first, by a year,
eludes them ;)

MvanL> That makes Pascal even MORE outdated.

as is C ;)

MvanL> Err no, C is continually in use for serious
MvanL> programming and will outlast Pascal.

err, yes... C is as outdated as Pascal... by your definition, anyway... so make
up your mind, eh?

)\/(ark


* Origin: (1:3634/12)

MvanL> dropfile and "those" dorinfo(x|#).def dropfiles ?

do you understand the meaning of "POST THE SPECS OR A LINK
TO THEM"?

MvanL> If you want specs then look in the source code.

do you understand the difference between specs and code? code isn't specs althought specs may contain sample code...

MvanL> Maximus creates "dorinfo1".def for ALL NODES, and always has.

ok [shrug]

you've still not provided the proof of this... i'm more
than willing to look at it once it is made available...
i would hope that it is written by the original author
of the dorinfox.def specification ;)

MvanL> http://en.wikipedia.org/wiki/Dropfile:

oh, cool... i'll go fix that right now...

MvanL> Haha you're not fixing anything, and merely
MvanL> demonstrating your pedantic childish need to challenge
MvanL> everything when the evidence is [...]

there is no evidence in that abandoned wikipedia article...

hint: don't take wikipedia as gospel...

I have obliged your request for documentation.

not with that link to wikipedia... obviously you don't know wikipedia and the policies they have, either ;)

[trim]

MvanL> You therefore are a victim of misinformation.

in this instance, your mistake is in believing unproven
and undocumented writtings that you read on wikipedia

MvanL> By the same token your mistakes derive from your poor
MvanL> deductive abilities.

i can, at least, program in whatever language i choose to for the job at hand... even if it is Pascal, which you just toss off as being out of date due to its age with total disregard for the fact that your chosen language is just as old and out of tune with today's reality...

whatever, you just go right on ahead building that negative karma, eh? ;)

)\/(ark


* Origin: (1:3634/12)

yup... your's is coming, too ;)

MvanL> That's what you think.

that's what i know... without a doubt... life works
that way and you are not immune to it no matter how
much miney you have, how greedy you are, or even how
angry you get... it _will_ happen...

That's absolute rubbish.

What I know, without a doubt, is life works the way I want and envisage. I create my own destiny. Not you, not idiotic ideas that abdicate responsibility and social governence like karma.

I'm getting a moral lecture from a guy who rather than seize the opportunity to
prove his spiritual integrity to the Universe you consciously chose to exact revenge and are still exhibiting the same vindictive behaviour to this day (at me) with insidious tactics because that's the best you can come up with.

If you're a person morally capable of leaving someone in jail for months even after they asked you for help under such desperate circumstances - why should I
believe anything you say ? I personally would not vouch or recommend anybody trust in or rely on you anyway.

If you believe what goes around comes around, then conversely you have nothing to blame but yourself for receiving ill treatment. The premises of your belief suggests that your own misdeeds, not those of others, culminated your own misfortune.

You sound like a child for using lame mysticism-based fears to impose righteous
guilt on others.

Wake up. Shit happens. Deal with it.

Your manipulative voodoo tricks don't work on me.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> That makes Pascal even MORE outdated.

as is C ;)

MvanL> Err no, C is continually in use for serious
MvanL> programming and will outlast Pascal.

err, yes... C is as outdated as Pascal... by your
definition, anyway... so make up your mind, eh?

You definitely are a skitzoid, trying to argue that C is just as "outdated" as (standard) Pascal when only a relative handful of people still use it and nowhere on earth and/or any respectible institution etc. would nowadays promote
it (Pascal), or any company dare touch it, while everywhere else C is being used for serious programming.

Pascal is obsolete junk by comparison.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

MvanL> Maximus creates "dorinfo1".def for ALL NODES, and always has.

ok [shrug]

That's right. You lose.

i can, at least, program in whatever language i choose
to for the job at hand... even if it is Pascal, which
you just toss off as being out of date due to its age
with total disregard for the fact that your chosen
language is just as old and out of tune with today's
reality...

Err no, Pascal is used by old fart Fidonet programmers with rapidly fading grasps on reality while C is being used for kernels, Operating Systems, device drivers, embedded devices and other serious programming.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

My stance on the dorinfo1.def subject is that I've
always just gone with whatever the door required. Most

That's what I said in the first place (!).

But NOooo it wasn't good enough for Mark Lewis.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

My stance on the dorinfo1.def subject is that I've
always just gone with whatever the door required.

MvanL> That's what I said in the first place (!).

MvanL> But NOooo it wasn't good enough for Mark Lewis.

amazing how you lost sight of the discussion when the thread split into multiple parts and then unraveled further :(

)\/(ark


* Origin: (1:3634/12)