% FDN: WCF: Wildcat!
% Coordinator: Ben Ritchey, 1:393/68, fido4cmech@lusfiber.net
% Internet: http://cmech.dynip.com/filebase.bbs/wcf4utl/
% http://cmech.dynip.com/filebase.bbs/wcf6utl/
Area WCF_4UTL 0 ! WCF: Wildcat! BBS v4.20 Utilities
Area WCF_6UTL 0 ! WCF: Winserver v6 Utilities
%
%

Thanks Ben!

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)

Hello Janis!

Thursday March 17 2016 21:34, you wrote to All:

% FDN: WCF: Wildcat!
% Coordinator: Ben Ritchey, 1:393/68, fido4cmech@lusfiber.net
% Internet: http://cmech.dynip.com/filebase.bbs/wcf4utl/
% http://cmech.dynip.com/filebase.bbs/wcf6utl/
Area WCF_4UTL 0 ! WCF: Wildcat! BBS v4.20 Utilities
Area WCF_6UTL 0 ! WCF: Winserver v6 Utilities
%
%

Just have a few through coming across and had a look at one namely PKTDATE

This has file dates of 2000 along with the C source code but is missing one file namely PKTDATE.lng, so it can not be compiled.

Pretty useless really ...



Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hi Vince,

Thursday March 17 2016 21:34, you wrote to All:

% FDN: WCF: Wildcat!
% Coordinator: Ben Ritchey, 1:393/68, fido4cmech@lusfiber.net
% Internet: http://cmech.dynip.com/filebase.bbs/wcf4utl/
% http://cmech.dynip.com/filebase.bbs/wcf6utl/
Area WCF_4UTL 0 ! WCF: Wildcat! BBS v4.20 Utilities
Area WCF_6UTL 0 ! WCF: Winserver v6 Utilities
%
%

Just have a few through coming across and had a look at one namely PKTDATE

This has file dates of 2000 along with the C source code but is missing one file namely PKTDATE.lng, so it can not be compiled.

Pretty useless really ...

Yes, know what you mean there. I'll have to look at what went through..

There are other files that came through Ben's new areas that don't exactly seem
"new" either... not what I'd expected... though I do have to examine the files in more detail.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)

* An ongoing debate between Janis Kracht and Vince Coen rages on ...

This has file dates of 2000 along with the C source code but is
missing one file namely PKTDATE.lng, so it can not be compiled.

I will re-hatch this with the missing file if available ... these files were recently requested via Facebook for WC4 installations so I am making it available once again. :) The original full archive I believe is available in FIDO Coordinator Utilities area (Y2kTool6), but this is just a few "special" need programs for WC4 systems :)

There are other files that came through Ben's new areas that don't
exactly seem "new" either... not what I'd expected... though I do have
to examine the files in more detail.

None of the WC6 files are "new", except maybe one, but they are certainly new to FIDONet/Filegate. Is there a problem?

--
Guardien Fide :^)

Ben aka cMech Web: http://cmech.dynip.com
Email: fido4cmech(at)lusfiber.net
Home page: http://cmech.dynip.com/homepage/
WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1

--- GoldED+/W32-MSVC
* Origin: FIDONet - The Positronium Repository (1:393/68)

Hi Ben,

This has file dates of 2000 along with the C source code but is
missing one file namely PKTDATE.lng, so it can not be compiled.

I will re-hatch this with the missing file if available ... these files were recently requested via Facebook for WC4 installations so I am making it available once again. :) The original full archive I believe is available in FIDO Coordinator Utilities area (Y2kTool6), but this is just a few "special" need programs for WC4 systems :)

I saw Pkdate come through with the added file. Thanks. But correct me if I'm wrong, what you released is really not changed source from what was already sent out? Just kind of repackaged?

There are other files that came through Ben's new areas that don't
exactly seem "new" either... not what I'd expected... though I do have
to examine the files in more detail.

None of the WC6 files are "new", except maybe one, but they are certainly new to FIDONet/Filegate. Is there a problem?

Don't forget Robert Wolfe has sent a lot of files through the filegate. :)

I haven't had time to check those WCF_6* files yet, but if Robert hasn't sent you an update personally, the files might have possibly come through the filegate already in the WINSERVER file echo (that's in Win_FDN), or some others
that Robert had released files in.

Just download my files.zip file, and do a grep for Robert Wolfe and you will see what I mean.

Don't get me wrong, I think it would be GREAT if Robert is indeed sending you new updates to the files he's already sent out, or if you've updated source where possible/applicable, otherwise... <g>

We surely don't expect you to rehatch files that perhaps are new to your system, but have already been been released, and I don't think you want to do that either :) :)

Thanks Ben,
Janis

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)

* An ongoing debate between Janis Kracht and Ben Ritchey rages on ...

I saw Pkdate come through with the added file. Thanks. But correct
me if I'm wrong, what you released is really not changed source from
what was already sent out? Just kind of repackaged?

Several WC4 Sysops expressed interest in the program(s) via FB so I created a custom archive applicable ONLY to WC4 Sysops (Robert was one of these). Not something I usually do, but this made it easier to implement the utility (the original archive had quite a few unnecessary files for this application). Don't
worry I avoid duplication except as noted above (g)

Don't forget Robert Wolfe has sent a lot of files through the
filegate. :)

Ok, he didn't mention any of this when I offered to hatch out his software {groan} so I will stick to recent updates if he's not still channeling them thru the WIN FDN. No problem ... I'll contact him :)

--
Guardien Fide :^)

Ben aka cMech Web: http://cmech.dynip.com
Email: fido4cmech(at)lusfiber.net
Home page: http://cmech.dynip.com/homepage/
WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1

--- GoldED+/W32-MSVC
* Origin: FIDONet - The Positronium Repository (1:393/68)

Hello Janis!

Wednesday March 23 2016 12:55, you wrote to Ben Ritchey:


The file PKTDATE.ZIP was missing a file PKTDATE.LNG and now the refreshed archive has come through I tried to compile it using cc under Linux but it reported three primary errors which makes me think that this source is not the latest that was produced but my system does not have wildcat files any more that I can see, as the system is over 15 years old and closed/commercial sources etc.

For the larger systems that have maintained the Wildcat file areas from the 80/90's there are just a re-issue of the originals that might create problems for those systems. In my case my decision on re-creating these file areas are subject to see what comes down the pike as it were but the bbs system itself seems to be a abandon commercial product so is it worth while?

That said a working source copy of pktdate might be useful not that I have seen
bad dates on net or echo mail but ....



Vince

Hi Ben,

This has file dates of 2000 along with the C source code but is
missing one file namely PKTDATE.lng, so it can not be compiled.

I will re-hatch this with the missing file if available ... these
files were recently requested via Facebook for WC4 installations so
I am making it available once again. :) The original full archive I
believe is available in FIDO Coordinator Utilities area (Y2kTool6),
but this is just a few "special" need programs for WC4 systems :)

I saw Pkdate come through with the added file. Thanks. But correct
me if I'm wrong, what you released is really not changed source from
what was already sent out? Just kind of repackaged?

There are other files that came through Ben's new areas that don't
exactly seem "new" either... not what I'd expected... though I do
have to examine the files in more detail.

None of the WC6 files are "new", except maybe one, but they are
certainly new to FIDONet/Filegate. Is there a problem?

Don't forget Robert Wolfe has sent a lot of files through the
filegate. :)

I haven't had time to check those WCF_6* files yet, but if Robert
hasn't sent you an update personally, the files might have possibly
come through the filegate already in the WINSERVER file echo (that's
in Win_FDN), or some others that Robert had released files in.

Just download my files.zip file, and do a grep for Robert Wolfe and
you will see what I mean.

Don't get me wrong, I think it would be GREAT if Robert is indeed
sending you new updates to the files he's already sent out, or if
you've updated source where possible/applicable, otherwise... <g>

We surely don't expect you to rehatch files that perhaps are new to
your system, but have already been been released, and I don't think
you want to do that either :) :)

Thanks Ben,
Janis

Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

24 Mar 16 14:43, you wrote to Janis Kracht:

That said a working source copy of pktdate might be useful not that I
have seen bad dates on net or echo mail but ....

apparently you do not have folks feeding from your system that get nostalgic and restore their old BBS setup from 15+ year old tapes or CDs... BBS software that is not y2k compatible... software that mucks up the year because the code doesn't do modulo arithmetic [eg: "year = (year-1900) mod 100"]... they get a result of 1xx when they subtract 1900 from the current year while trying to make it a two digit year because they use math manipulation instead of string manipulation... this is a quite common problem seen in C code of that era... it
is sometimes seen in code written in other languages but it is very common in C
code... today, that code will return 116 for the year after they subtract 1900 and don't modulo it...

that's only ONE of the various problems that can happen... depending on the rest of the processing it may make the PKT header one byte too long or it could
result in the last byte of the PKT header being truncated... then you get to the dates in the packed messages and they could have headers that are one byte too long or be the proper length but missing the last byte of the message header...

anyway, i thought i'd toss that out there to try to help explain the problem of
non-y2k compliant software and the possible date problems they can cause...

)\/(ark

Always Mount a Scratch Monkey

... Buffet: French for making a pig of yourself.
---
* Origin: (1:3634/12.73)

Hello mark!

Thursday March 24 2016 13:28, you wrote to me:

That said a working source copy of pktdate might be useful not
that I have seen bad dates on net or echo mail but ....

apparently you do not have folks feeding from your system that get
nostalgic and restore their old BBS setup from 15+ year old tapes or
CDs... BBS software that is not y2k compatible... software that mucks
up the year because the code doesn't do modulo arithmetic [eg: "year = (year-1900) mod 100"]... they get a result of 1xx when they subtract
1900 from the current year while trying to make it a two digit year
because they use math manipulation instead of string manipulation...
this is a quite common problem seen in C code of that era... it is
sometimes seen in code written in other languages but it is very
common in C code... today, that code will return 116 for the year
after they subtract 1900 and don't modulo it...

that's only ONE of the various problems that can happen... depending
on the rest of the processing it may make the PKT header one byte too
long or it could result in the last byte of the PKT header being truncated... then you get to the dates in the packed messages and they
could have headers that are one byte too long or be the proper length
but missing the last byte of the message header...

anyway, i thought i'd toss that out there to try to help explain the
problem of non-y2k compliant software and the possible date problems
they can cause...

Hmm, thanks for that, I have not noticed it but - I do not look and the mail from all of the areas that come through here.

In that case I should try and install it but still have the issue of the compiling warnings. If I can clear thoese I can plug it in to mbse.

For your interest here is the o/p from the attempt to compile it under Mageia v5 X64 Linux : -

-----------
[mbse@Applewood a]$ gcc pktdate.c
pktdate.c:38:6: warning: conflicting types for built-in function 'log'
void log(int loglevel, const char *fmt, ...);
^
pktdate.c: In function 'process_pkt':
pktdate.c:152:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
pktdate.c:159:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
/tmp/ccoDkgoG.o: In function `write_pkt':
pktdate.c:(.text+0xe5c): warning: the use of `tmpnam' is dangerous, better use `mkstemp'

-----------

No I don't understand them other than a basic level :(


Vince

--- Mageia Linux v5/Mbse v1.0.6/GoldED+/LNX 1.1.501-b20150715
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hi Vince,

For your interest here is the o/p from the attempt to compile it under Mageia v5 X64 Linux : -

-----------
[mbse@Applewood a]$ gcc pktdate.c
pktdate.c:38:6: warning: conflicting types for built-in function 'log'
void log(int loglevel, const char *fmt, ...);
^
pktdate.c: In function 'process_pkt':
pktdate.c:152:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
pktdate.c:159:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
/tmp/ccoDkgoG.o: In function `write_pkt':
pktdate.c:(.text+0xe5c): warning: the use of `tmpnam' is dangerous, better use
`mkstemp'

-----------

No I don't understand them other than a basic level :(

It compiled here on my linux box.. same warnings as you saw but the compile did
create a file named a.out.

Because there was no makefile, the binary is named a.out here - which runs on the command like, if you type for example:

./a.out


Pktdate Rev. 1.5, written by Tobias Ernst @ 2:2476/418 et al.

Error: No arguments given.


I didn't give any arguments, but now that I see them listed, I can rename a.out
to pktdate and go from there.. should work fine.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)

Hi Vince,

For your interest here is the o/p from the attempt to compile it under Mageia v5 X64 Linux : -

-----------
[mbse@Applewood a]$ gcc pktdate.c
pktdate.c:38:6: warning: conflicting types for built-in function 'log'
void log(int loglevel, const char *fmt, ...);
^
pktdate.c: In function 'process_pkt':
pktdate.c:152:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
pktdate.c:159:9: warning: overflow in implicit constant conversion [-Woverflow]
return FATAL_ERROR;
^
/tmp/ccoDkgoG.o: In function `write_pkt':
pktdate.c:(.text+0xe5c): warning: the use of `tmpnam' is dangerous, better use
`mkstemp'

-----------

No I don't understand them other than a basic level :(

It compiled here on my linux box.. same warnings as you saw but the compile did
create a file named a.out.

Because there was no makefile, the binary is named a.out here - which runs on the command like, if you type for example:

./a.out


Pktdate Rev. 1.5, written by Tobias Ernst @ 2:2476/418 et al.

Error: No arguments given.

Usage: pktdate [<language>] [<option> ...] <filename> [<filename> ...] [...]

I didn't give any arguments, but now that I see them listed, I can rename a.out
to pktdate and go from there.. should work fine.

Take care,
Janis

--- BBBS/Li6 v4.10 Dada-2
* Origin: Prism bbs (1:261/38)

Added this evening:

% FDN: INTERMAIL Mailer FDN
% Coordinator Dale Barnes, 1:1/133 (dalebarnes42@majik.net)
%
% PATH: DIRECT
% HUB: No
% ------------------------------------------------------------------------
% File Echo Description
% ------------------------------------------------------------------------
Area INTRMAIL 0 ! INTR: Intermail Mailer
%
%

--- BBBS/Li6 v4.10 Toy-3
* Origin: Prism bbs (1:261/38)