• not ignoring you... but...

    From Dan Egli@1:311/6 to Wayne Steele on Sun Jul 4 01:48:00 2004
    Hey Wayne,

    03 Jul 04 12:01, you wrote to All:

    Hi All,

    I've done further investigations into this EleBBS/WEB 1 day message problem and found that if I have a hudson or a Squish message base
    the DATE is correct so it is only in a JAM message area... As far as
    I can tell EleBBS uses Mark May's Source code... So would this narrow
    it down to maybe a MKMSGJAM.PAS problem?

    Sorry for not replying to anyones message but been working heaps of
    late work/sleep is my day 2 days off now...

    Likely place to start. If you do find the issue and fix it, mind Netmailing or E-mailing the updated PAS file to me so I can include it in the next EleBBS release (whenever that is)?

    -- Dan

    --- FMail/Win32 1.60
    * Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)
  • From mark lewis@1:3634/12 to Wayne Steele on Wed Jul 7 00:42:20 2004
    I've done further investigations into this EleBBS/WEB
    1 day message problem and found that if I have a hudson
    or a Squish message base the DATE is correct so it is
    only in a JAM message area... As far as I can tell
    EleBBS uses Mark May's Source code... So would this
    narrow it down to maybe a MKMSGJAM.PAS problem?

    that is interesting... i wasn't aware that they were using mark may's stuff... it does make sense, though...

    i found and patched numerous bugs in mark's stuff over the years... i don't recall what those fixes were nor did i mark them down anywhere or comment them with IDs in the code... however, i'm willing to make what i have available for others to look at...

    FWIW: i have several tools that create messages in JAM bases and they all use mark's code... none of them exhibit this problem...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Wayne Steele on Wed Jul 7 01:49:04 2004
    FWIW: i have several tools that create messages in JAM bases
    and they all use mark's code... none of them exhibit this
    problem...

    this got out before i had a chance to add this...

    i just looked at the MKMSGJAM that i have and i do see these two notes at the top...

    {
    changed MSGTIME from 5 characters to 8 characters to get real seconds
    instead of forcing them to zero.
    MFL - 13 June 96

    added SETATTR procedure to allow specific access to attributes
    MFL - 9 June 96
    }


    it is possible that i may have fixed something else, too...

    i note that the date stuff is also run thru several conversions... the date is run thru DTToUnixDate which converts the borland DT (datetime) format to unixtime format... unixtime format is the number of seconds since 1970, IIRC...
    part of that process is to convert the days past from gregorian to julian...

    here are those routines and the few variables... check that you find them as so
    in your code...

    [from MKMISC.PAS]

    Const
    C1970 = 2440588;
    D0 = 1461;
    D1 = 146097;
    D2 = 1721119;

    [...]

    {$IFDEF WINDOWS}
    Function GregorianToJulian(DT: TDateTime): LongInt;
    {$ELSE}
    Function GregorianToJulian(DT: DateTime): LongInt;
    {$ENDIF}
    Var
    Century: LongInt;
    XYear: LongInt;
    Temp: LongInt;
    Month: LongInt;

    Begin
    Month := DT.Month;
    If Month <= 2 Then
    Begin
    Dec(DT.Year);
    Inc(Month,12);
    End;
    Dec(Month,3);
    Century := DT.Year Div 100;
    XYear := DT.Year Mod 100;
    Century := (Century * D1) shr 2;
    XYear := (XYear * D0) shr 2;
    GregorianToJulian := ((((Month * 153) + 2) div 5) + DT.Day) + D2
    + XYear + Century;
    End;

    [...]

    {$IFDEF WINDOWS}
    Function DTToUnixDate(DT: TDateTime): LongInt;
    {$ELSE}
    Function DTToUnixDate(DT: DateTime): LongInt;
    {$ENDIF}
    Var
    SecsPast, DaysPast: LongInt;

    Begin
    DaysPast := GregorianToJulian(DT) - c1970;
    SecsPast := DaysPast * 86400;
    SecsPast := SecsPast + (LongInt(DT.Hour) * 3600) + (DT.Min * 60) + (DT.Sec);
    DTToUnixDate := SecsPast;
    End;

    [... and then back to the routine in MKMSGJAM.PAS ...]

    Function JamMsgObj.WriteMsg: Word;
    Var
    {$IFDEF WINDOWS}
    DT: TDateTime;
    {$ELSE}
    DT: DateTime;
    {$ENDIF}
    WriteError: Word;
    i: Word;
    TmpIdx: JamIdxType;

    Begin
    WriteError := 0;
    If LastSoft Then
    Begin
    DoChar(#13);
    DoChar(#10);
    End;
    If WriteError = 0 Then
    Begin
    MsgHdr^.JamHdr.Signature[1] := 'J';{Set signature}
    MsgHdr^.JamHdr.Signature[2] := 'A';
    MsgHdr^.JamHdr.Signature[3] := 'M';
    MsgHdr^.JamHdr.Signature[4] := #0;
    Case JM^.MailType of
    mmtNormal: SetAttr1(Jam_TypeLocal, True);
    mmtEchoMail: SetAttr1(Jam_TypeEcho, True);
    mmtNetMail: SetAttr1(Jam_TypeNet, True);
    End;
    MsgHdr^.JamHdr.Rev := 1;
    MsgHdr^.JamHdr.DateArrived := ToUnixDate(GetDosDate); {Get date processed}
    DT.Year := Str2Long(Copy(JM^.MsgDate, 7, 2)); {Convert date written}
    DT.Month := Str2Long(Copy(JM^.MsgDate, 1, 2));
    DT.Day := Str2Long(Copy(JM^.MsgDate, 4, 2));
    If DT.Year < 80 Then
    Inc(DT.Year, 2000)
    Else
    Inc(DT.Year, 1900);
    { DT.Sec := 0; }
    DT.Sec := Str2Long(Copy(JM^.MsgTime, 7, 2));
    DT.Hour := Str2Long(Copy(JM^.MsgTime, 1, 2));
    DT.Min := Str2Long(Copy(JM^.MsgTime, 4, 2));
    MsgHdr^.JamHdr.DateWritten := DTToUnixDate(DT);
    End;

    there is more code in this routine but this is the code leading up to the setting of the date written... do you have the same problem with the setting of
    the date arrived? they should be the same for locally (on the bbs) written messages... you can see my alteration as noted for setting actual seconds in the time field instead of forcing them to zero... i did this alteration in an effort to get around buggy code that thinks that numerous messages written in the same second are duplicates... i have tested my stuff from this blackbox library at generating several hundred messages per minutes without then being caught as dupes ;)


    tracing a bit "further on", we find this code...

    Procedure JamMsgObj.StartNewMsg;
    Begin
    JM^.TxtBufStart := 0;
    JM^.TxtPos := 0;
    FillChar(MsgHdr^, SizeOf(MsgHdr^), #0);
    MsgHdr^.JamHdr.SubFieldLen := 0;
    MsgHdr^.JamHdr.MsgIdCrc := -1;
    MsgHdr^.JamHdr.ReplyCrc := -1;
    MsgHdr^.JamHdr.PwdCrc := -1;
    JM^.MsgTo := '';
    JM^.MsgFrom := '';
    JM^.MsgSubj := '';
    FillChar(JM^.Orig, SizeOf(JM^.Orig), #0);
    FillChar(JM^.Dest, SizeOf(JM^.Dest), #0);
    JM^.MsgDate := DateStr(GetDosDate);
    JM^.MsgTime := TimeStr(GetDosDate);
    End;

    this indicates that the date the message is written comes from the GetDosDate routine... that's a simple routine that gets the date and time from the system clock and packs it into the longint that GetDosDate returns...

    from what i can tell, StartNewMsg is the first place in the code that the date of the message is set and its done automatically by the above which just reads the system clock...

    [time passes]

    i see in my code that i do the following...

    init the message == StartNewMsg
    set the addresses to/from == SetDest and SetOrig
    set the attributes == many Set* routines
    put the control lines == DoStringLn and/or DoKludgeLn
    load the message text body == DoString and DoStringLn
    write the message to the message base == WriteMsg

    i note that when i set the attributes, that i also set the date in the same basic way that was already done... i don't remember why i set the date again...
    possibly because it wasn't being done when i first started using the msg kit and then after some updates, it was... no matter, really, both use the same DateStr(GetDosDate)... i do mine with the SetDate routine whereas the other is
    done directly into the same JM^.MsgDate variable... i could do this also via msgout^.JM^.MsgDate IIRC but the SetDate routine is easier since it is supposed
    to be used in a blackbox fashion ;)

    DateStr formats the date to MM-DD-YY format with leading zeros where needed...

    am i going to have to go digging thru the Elebbs code? OB-)

    )\/(ark


    * Origin: (1:3634/12)
  • From Dan Egli@1:311/6 to mark lewis on Wed Jul 7 19:53:18 2004
    Hey mark,

    07 Jul 04 00:49, you wrote to Wayne Steele:

    FWIW: i have several tools that create messages in JAM bases
    and they all use mark's code... none of them exhibit this
    problem...

    this got out before i had a chance to add this...

    i just looked at the MKMSGJAM that i have and i do see these two notes
    at the top...

    {
    changed MSGTIME from 5 characters to 8 characters to get real
    seconds instead of forcing them to zero. MFL - 13 June 96

    added SETATTR procedure to allow specific access to attributes
    MFL - 9 June 96
    }

    Nice. Mark, would you netmail that unit to me? Since I am writing message base utils for EleBBS that might be handy to have. I wonder if Maarten is even still
    around anymore. Haven't heard from him in the echo for over a year I think.


    -- Dan

    --- FMail/Win32 1.60
    * Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)
  • From mark lewis@1:3634/12 to Dan Egli on Thu Jul 8 16:58:54 2004
    i just looked at the MKMSGJAM that i have and i do see these
    two notes at the top...

    {
    changed MSGTIME from 5 characters to 8 characters to get real
    seconds instead of forcing them to zero. MFL - 13 June 96

    added SETATTR procedure to allow specific access to attributes
    MFL - 9 June 96
    }

    Nice. Mark, would you netmail that unit to me?

    i can get it together and make it available but first i'd like to see if i can get hold of mark may and get approval for releasing my mods... note that i've only worked with this under TP6... i believe that i did do some experimenting with BP6... i've not tried to use it at all under delphi or any windows or os/2
    native pascal compilers...

    Since I am writing message base utils for EleBBS that might
    be handy to have. I wonder if Maarten is even still around
    anymore. Haven't heard from him in the echo for over a year
    I think.

    i don't know if he is still around or not...

    further on my mods, i remember fixing one bug that would cause control lines to
    be skipped... the fix was to add a simple DEC() call since the routine was one character too far ahead to see the start of the next control line... the result
    was that every other control line was missed...

    i know there were other things, too... just kinda wish i had documented them more... one thing that i've been wanting to do was to incorporate the filebuffering stuff into those other message base formats that don't have it...
    MSG and JAM are the only two that use it and mark never got around to putting it in all of them before releasing his bbs source code with mkmsg in it...

    )\/(ark


    * Origin: (1:3634/12)
  • From Scott Little@3:712/848 to Wayne Steele on Fri Jul 9 06:26:04 2004
    [ 03 Jul 04 12:01, Wayne Steele wrote to All ]

    I've done further investigations into this EleBBS/WEB 1 day message problem and found that if I have a hudson or a Squish message base
    the DATE is correct so it is only in a JAM message area... As far as
    I can tell EleBBS uses Mark May's Source code... So would this narrow
    it down to maybe a MKMSGJAM.PAS problem?

    Gawd DAY-EM! What a rats' nest.

    First, you should have your TZ environment variable set. TZ=EST-10 if you're in Sydney/Melb/etc.

    Second, it looks like unix2norm() is FUBAR. Which is really odd since a simple
    unix2norm(norm2unix()) would tell you it's broken, and this is a piece of code that's been floating around for ages (and obviously used by many people). The fix eludes me (at 5am), so I rewrote it. This isn't well tested, but it Works For Me. I can compile Win32 and Linux binaries, if you're running OS/2 or something you'll have to compile it yourself. Just replace unix2norm with the following in elebbs/src/unixdate.pas.



    Procedure Unix2Norm(Date: LongInt; var Year, Month, Day, Hour, Min, Sec: Word);

    (* Scott Little, 2004-07-04
    "Day" was always one day late, except for the first day of the month.
    Couldn't fix. Rewrote. Untested.
    *)

    var
    Done : Boolean;
    X : ShortInt;
    TotDays : Integer;
    begin
    Year := 1970;
    Month := 01;
    Day := 01;
    Hour := 00;
    Min := 00;
    Sec := 00;

    Date := Date + (GetTimeZone * SecsPerHour); { Local time/date }

    while Date >= SecsPerYear do
    begin
    if IsLeapYear(Year) and (Date < SecsPerLeapYear) then
    break;

    if IsLeapYear(Year) and (Date >= SecsPerLeapYear) then
    begin
    Inc(Year, 1);
    Dec(Date, SecsPerLeapYear);
    end
    else
    begin
    Inc(Year, 1);
    Dec(Date, SecsPerYear);
    end;
    end;

    TotDays := Date DIV SecsPerDay;

    for X := 12 downto 1 do
    begin
    if X = 1 then
    break;

    if isLeapYear(Year) and (TotDays >= DaysPerLeapYear[X - 1]) then
    begin
    Dec(Date, DaysPerLeapYear[X - 1] * SecsPerDay);
    Dec(Totdays, DaysPerLeapYear[X - 1]);
    break;
    end
    else if (not isLeapYear(Year)) and (TotDays >= DaysPerYear[X - 1]) then
    begin
    Dec(Date, DaysPerYear[X - 1] * SecsPerDay);
    Dec(Totdays, DaysPerYear[X - 1]);
    break;
    end;
    end;

    Month := X;

    Day := TotDays + 1;
    Dec(Date, (Day - 1) * SecsPerDay);

    Hour := Date DIV SecsPerHour;
    Dec(Date, Hour * SecsPerHour);

    Min := Date DIV SecsPerMinute;
    Dec(Date, Min * SecsPerMinute);

    Sec := Date;

    end; { proc. Unix2Norm }



    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From Dan Egli@1:311/6 to mark lewis on Fri Jul 9 10:19:30 2004
    Hey mark,

    08 Jul 04 15:58, you wrote to me:

    i can get it together and make it available but first i'd like to see
    if i can get hold of mark may and get approval for releasing my
    mods... note that i've only worked with this under TP6... i believe
    that i did do some experimenting with BP6... i've not tried to use it
    at all under delphi or any windows or os/2 native pascal compilers...

    Should be compatable. But if not either I'll enlist your help in fixing it or just hack at it myself.

    Since I am writing message base utils for EleBBS that might
    be handy to have. I wonder if Maarten is even still around
    anymore. Haven't heard from him in the echo for over a year
    I think.

    i don't know if he is still around or not...

    Netiher do I. Which is why I adopted EleBBS sorta. I've had three BBS software's I use abandoned, I don't want to make it #4. Teleard, TAG, and RemoteAccess all were abandoned by their author. Yes Telegard and RA were picked up again, but they also seem to have been dropped again. I'm determined to not let that happen to EleBBS untill no one is using it, or till I just cann't do it anymore.

    -- Dan

    --- FMail/Win32 1.60
    * Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)
  • From mark lewis@1:3634/12 to Scott Little on Fri Jul 9 14:44:16 2004
    I've done further investigations into this EleBBS/WEB
    1 day message problem and found that if I have a
    hudson or a Squish message base the DATE is correct
    so it is only in a JAM message area... As far as I
    can tell EleBBS uses Mark May's Source code... So
    would this narrow it down to maybe a MKMSGJAM.PAS
    problem?

    Gawd DAY-EM! What a rats' nest.

    where? in ele or the mk library?

    First, you should have your TZ environment variable set.
    TZ=EST-10 if you're in Sydney/Melb/etc.

    Second, it looks like unix2norm() is FUBAR. Which is really

    i don't see unix2norm in the mkmsg stuff... it must be something in the ele code...

    odd since a simple unix2norm(norm2unix()) would tell you it's
    broken,

    hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses UnixToDT
    and DTToUnix to convert the datetime record format back and forth...

    and this is a piece of code that's been floating around for
    ages (and obviously used by many people).

    makes me even more curious, now...

    The fix eludes me (at 5am), so I rewrote it. This isn't
    well tested, but it Works For Me.

    did you test leapyears ;)

    I can compile Win32 and Linux binaries, if you're running
    OS/2 or something you'll have to compile it yourself.
    Just replace unix2norm with the following in
    elebbs/src/unixdate.pas.

    ahhh... thought it would have to have been some ele code and not the mkmsg code...

    Procedure Unix2Norm(Date: LongInt; var Year, Month, Day, Hour,
    Min, Sec: Word);

    hummm... very similar to the datetime record format... just all in pieces instead of in one record...

    )\/(ark


    * Origin: (1:3634/12)
  • From Scott Little@3:712/848 to mark lewis on Sat Jul 10 08:13:26 2004
    [ 09 Jul 04 13:44, mark lewis wrote to Scott Little ]

    Gawd DAY-EM! What a rats' nest.
    where? in ele or the mk library?

    Ele. The ifdefs.... awmigawd the ifdefs... *cries*

    odd since a simple unix2norm(norm2unix()) would tell you it's
    broken,

    hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses UnixToDT and DTToUnix to convert the datetime record format back and forth...

    The mkmsgjam.pas in the Ele source tree has been modified to use unixdate.pas and jdates.pas from the parent (elebbs) directory. In fact, the whole mkmsg source included with Ele has been drastically pruned.

    The original mkmsg source (v1.04 is what I have) uses a different algorithm. I'll have a look at it later and see if it's accurate, if so I'll massage it into unix2norm() form, since it's no doubt much more tested than my code.

    and this is a piece of code that's been floating around for
    ages (and obviously used by many people).
    makes me even more curious, now...

    It's from SWAG, BTW. And the first whole page of hits off Google for any searches mentioning unix, dates, and Pascal.

    The fix eludes me (at 5am), so I rewrote it. This isn't
    well tested, but it Works For Me.
    did you test leapyears ;)

    Of course :)

    It doesn't take into consideration leapseconds or any of that other stuff though. But a few seconds here and there over a couple of decades is accurate enough for our purposes.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From mark lewis@1:3634/12 to Dan Egli on Fri Jul 9 18:00:14 2004
    Netiher do I. Which is why I adopted EleBBS sorta. I've had
    three BBS software's I use abandoned, I don't want to make it
    #4. Teleard, TAG, and RemoteAccess all were abandoned by their
    author. Yes Telegard and RA were picked up again, but they
    also seem to have been dropped again. I'm determined to not
    let that happen to EleBBS untill no one is using it, or till I
    just cann't do it anymore.

    understand that... what compiler are you using? what OS' are you compiling for?
    where is the project based?

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Scott Little on Fri Jul 9 23:30:58 2004
    Gawd DAY-EM! What a rats' nest.
    where? in ele or the mk library?

    Ele. The ifdefs.... awmigawd the ifdefs... *cries*

    i can imagine... i've thought about taking a look and seeing what i can see... maybe not, now ;)

    odd since a simple unix2norm(norm2unix()) would tell you it's
    broken,

    hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses
    UnixToDT and DTToUnix to convert the datetime record format back and
    forth...

    The mkmsgjam.pas in the Ele source tree has been modified to
    use unixdate.pas and jdates.pas from the parent (elebbs)
    directory. In fact, the whole mkmsg source included with Ele
    has been drastically pruned.

    ouch... that may not be a good thing...

    The original mkmsg source (v1.04 is what I have) uses a
    different algorithm. I'll have a look at it later and see if
    it's accurate, if so I'll massage it into unix2norm() form,
    since it's no doubt much more tested than my code.

    ahh, yes, v1.06 made several fixes and implemented filebuffering for large message capablity... JAM and MSG are now limited only to available drive space or max message base size, IIRC... can you imagine a 4terabyte message O%-)

    and this is a piece of code that's been floating around for
    ages (and obviously used by many people).
    makes me even more curious, now...

    It's from SWAG, BTW. And the first whole page of hits off
    Google for any searches mentioning unix, dates, and Pascal.

    hummm... hey, i've got SWAG installed on my machine, IIRC... the last one released, anyway...

    [time passes]

    whoa! that brings back some memories... i've got 10 snippets in there... should
    be more but there are 10 with just my name on them...

    i found the unix2norm routine... its not anything like the stuff i use...

    The fix eludes me (at 5am), so I rewrote it. This isn't
    well tested, but it Works For Me.
    did you test leapyears ;)

    Of course :)

    It doesn't take into consideration leapseconds or any of that
    other stuff though. But a few seconds here and there over a
    couple of decades is accurate enough for our purposes.

    yup, my feelings, too...

    )\/(ark


    * Origin: (1:3634/12)
  • From Scott Little@3:712/848 to mark lewis on Sat Jul 10 22:13:52 2004
    [ 09 Jul 04 22:30, mark lewis wrote to Scott Little ]

    hummm... hey, i've got SWAG installed on my machine, IIRC... the last
    one released, anyway...

    What version? I have.. umm.. reader v3.13, and the most recent files are 1997-10-07.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From Scott Little@3:712/848 to mark lewis on Sat Jul 10 22:48:26 2004
    [ 09 Jul 04 22:30, mark lewis wrote to Scott Little ]

    ahh, yes, v1.06 made several fixes and implemented filebuffering for

    Hmm... it looks like v1.06 has the:

    BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
    to
    BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

    fix, but what about the:

    If JM^.TxtSubChars <= TxtSubBufSize Then
    to
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    one? Did that turn out not to be needed?


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From Björn Felten@2:203/208 to mark lewis on Sat Jul 10 19:12:46 2004
    i found the unix2norm routine... its not anything like
    the stuff i use...

    Here's one that I (and several others) have used for more than ten years now. Take it or leave it. :)

    - = * = -

    unit UnixUtil;

    { By Björn Felten @ 2:203/208. No rights reserved what so ever... :) }

    INTERFACE
    uses dos;

    function GetTimeZone: shortint;
    function IsLeapYear(Source: word): boolean;
    function Norm2Unix(var DT: datetime): longint;
    procedure Unix2Norm(Date: longint; var DT: datetime);
    function D1970(var DT: datetime): longint;

    IMPLEMENTATION

    const
    DaysPerMonth : array[1..12] of shortint
    = (31,28,31,30,31,30,31,31,30,31,30,31);
    SecsPerMinute : longint = 60;
    SecsPerHour : longint = 60 * 60;
    SecsPerDay : longint = 60 * 60 * 24;
    SecsPerYear : longint = 60 * 60 * 24 * 365;
    SecsPerLeapYear : longint = 60 * 60 * 24 * 366;


    function GetTimeZone;
    var Environment : string;
    I, E : integer;
    begin
    I := 0; {Assume UTC}
    Environment := getenv('TZ'); {Grab TZ string}
    if Environment<>'' then begin
    delete(Environment,1,3);
    val(Environment,I,E);
    if E>0 then begin
    delete(Environment,1,E);
    for E := 1 to length(Environment) do
    Environment[E] := Upcase(Environment[E]);
    if pos('DT',Environment)>0 then inc(I)
    end
    end;
    GetTimeZone := I
    end;

    function IsLeapYear;
    begin
    IsLeapYear := (Source and 3 = 0)
    end;

    function D1970; { Thanks to Paul Schlyter... }
    begin
    with DT do
    D1970 := longint(367) * Year
    - 7 * (Year + (Month + 9) div 12) div 4
    + 275 * Month div 9
    + Day
    - 719574
    end;

    function Norm2Unix;
    var UnixDate : longint;
    begin
    UnixDate := D1970(DT) * SecsPerDay; {days since 1970}
    with DT do begin
    inc(UnixDate,(SecsPerHour * Hour)); {add hours}
    inc(UnixDate,(SecsPerMinute * Min)); {add minutes}
    inc(UnixDate,Sec); {add seconds}
    UnixDate := UnixDate + (GetTimeZone * SecsPerHour) {add UTC offset}
    end; { with Date do }
    Norm2Unix := UnixDate
    end;

    procedure Unix2Norm;
    var SecsToLose, LocalDate: longint;

    procedure Split(var A: word; B: longint);
    begin
    A := LocalDate div B;
    LocalDate := LocalDate mod B
    end;

    begin
    with DT do begin
    Year := 1970;
    Month := 1;
    LocalDate := Date - (GetTimeZone * SecsPerHour); {Local time date}

    { sweep out the years }
    SecsToLose := SecsPerYear;
    while LocalDate >= SecsToLose do begin
    inc(Year,1);
    dec(LocalDate,SecsToLose);
    if IsLeapYear(Year)
    then SecsToLose := SecsPerLeapYear
    else SecsToLose := SecsPerYear
    end;

    { and now the months }
    Split(Day,SecsPerDay);
    if IsLeapYear(Year)
    then DaysPerMonth[02] := 29
    else DaysPerMonth[02] := 28; {Check for Feb. 29th}
    while Day >= DaysPerMonth[Month] do begin
    dec(Day,DaysPerMonth[Month]);
    inc(Month,1)
    end;

    { the rest is a piece of cake }
    inc(Day);
    Split(Hour,SecsPerHour);
    Split(Min,SecsPerMinute);
    Sec := LocalDate
    end { with DT do }
    end; { procedure UnixToNorm }

    end. { unit UnixTime }

    ---
    * Origin: -=P=I=X=- / Psion Info Xchange (+46-31-960447) (2:203/208)
  • From mark lewis@1:3634/12 to Scott Little on Sat Jul 10 14:11:38 2004
    hummm... hey, i've got SWAG installed on my machine,
    IIRC... the last one released, anyway...

    What version? I have.. umm.. reader v3.13, and the most
    recent files are 1997-10-07.

    yup, that's the latest/last version...

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Scott Little on Sat Jul 10 14:23:34 2004
    ahh, yes, v1.06 made several fixes and implemented filebuffering for

    Hmm... it looks like v1.06 has the:

    BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
    to
    BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

    fix,

    ok... i can see the change but am not fully aware of it being done... i had a list of fixes i thought... gotta go looking some more...

    [time passes]

    that looks like the

    v1.04 01/09/94

    [trim]

    - Fixed JAM writeidx to only write the amount that
    had been read

    fix...

    but what about the:

    If JM^.TxtSubChars <= TxtSubBufSize Then
    to
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    one?

    where? in here??

    Procedure JamMsgObj.AddTxtSub(St: String);
    Var
    i: Word;

    Begin
    For i := 1 to Length(St) Do
    Begin
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Begin
    JM^.TxtSubBuf[JM^.TxtSubChars] := St[i];
    Inc(JM^.TxtSubChars);
    End;
    End;
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Begin
    JM^.TxtSubBuf[JM^.TxtSubChars] := #13;
    Inc(JM^.TxtSubChars);
    End;
    End;

    if so, which one? i'm not aware of needing that change... all my stuff posted with my PostIt util uses this code all the time and i've not seen any problems with it... then again, my stuff only posts text files to message bases... i've not gone so far as to try to write a tosser or OLR with it...

    Did that turn out not to be needed?

    i really don't know... what were the problems without it? i don't see anything in CHANGES.MKS that would indicate that there was a fix in that area, either...
    what was that fix supposed to do??

    )\/(ark


    * Origin: (1:3634/12)
  • From Scott Little@3:712/848 to mark lewis on Sun Jul 11 07:28:16 2004
    [ 10 Jul 04 13:23, mark lewis wrote to Scott Little ]

    If JM^.TxtSubChars <= TxtSubBufSize Then
    to
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    if so, which one? i'm not aware of needing that change... all my stuff

    Stick "mkmsg bugs" into Google and hit "I'm Feeling Lucky":

    --\/--
    Contributor: FRANK VAN DER HAM

    {
    For all who work with the MkMsg toolbox and it's JAM unit, I share my experience with the deleting of messages.

    Despite a bugfix on this very subject from 1.02 to 1.03, I still cannot
    delete messages properly. I found out that the basis of the problem is the handling of the IDX file. First of all, the number of bytes written to the
    IDX file was invalid and, secondly, a real bug was in the handling of the
    "sub text" where an array is declared as "array [1..xx]" and used as "array [0..xx], causing a field in a record to be overriden to an invalid value.

    These are the changes I made to my MKMSGJAM.PAS file.

    Line 150:
    Change
    TxtSubBuf: Array[1..TxtSubBufSize] of Char; {temp storage ... }
    Into
    TxtSubBuf: Array[0..TxtSubBufSize-1] of Char; {temp storage ... }

    Line 831:
    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    Line 838:
    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    Line 1490:
    Change
    BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
    Into
    BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

    Keep on jammin' !
    --/\--


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From Scott Little@3:712/848 to Björn Felten on Sun Jul 11 07:33:26 2004
    [ 10 Jul 04 18:12, Björn Felten wrote to mark lewis ]

    function IsLeapYear;
    begin
    IsLeapYear := (Source and 3 = 0)
    end;

    Urm.. just to be a pedant,

    ((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

    :)


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From mark lewis@1:3634/12 to Scott Little on Sat Jul 10 19:20:04 2004
    If JM^.TxtSubChars <= TxtSubBufSize Then
    to
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    if so, which one? i'm not aware of needing that change... all my stuff

    Stick "mkmsg bugs" into Google and hit "I'm Feeling Lucky":

    hummm...

    --\/--
    Contributor: FRANK VAN DER HAM

    i recognize that name from the fixes file... he found several, it seems... my name is in there once or twice, too... but i sent more fixes than acknowledged...

    Line 150:
    Change
    TxtSubBuf: Array[1..TxtSubBufSize] of Char; {temp storage
    ... }
    Into
    TxtSubBuf: Array[0..TxtSubBufSize-1] of Char; {temp storage
    ... }

    yes, that's in my copy...

    Line 831:
    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    Line 838:
    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    neither of these is in my copy of 1.06...

    Line 1490:
    Change
    BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
    Into
    BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

    this is on line 1439 in my copy in the

    Function JamMsgObj.WriteIdx: Word;

    routine... looks like readidx and writeidx were moved out into seperate routines... i know that i added at least 9 lines at the top of the file as well
    as several others where i commented out a line i was changing to keep the original just in case... evidently there was a bit of movement in other areas, too... wonder what version of mkmsg that page covers??

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Scott Little on Sat Jul 10 19:38:28 2004
    Line 150:

    this line is +2 from 150 in the unmodified v1.06 i have...
    this line is +2 from 150 in the unmodified mkbbs code i have...

    Line 831:

    this line is -6 from 831 in the unmodified v1.06 i have...
    this line is -5 from 831 in the unmodified mkbbs code i have...
    neither has the -1 on the line...

    Line 838:

    this line is -7 from 838 in the unmodified v1.06 i have...
    this line is -6 from 838 in the unmodified mkbbs code i have...
    neither has the -1 on the line...

    Line 1490:

    this line is -65 from 1490 in the unmodified v1.06 i have...
    this line is -62 from 1490 in the unmodified mkbbs code i have...


    the MKMSGJAM.PAS in the mksm106 archive is dated dec 10 1994 01:06

    the MKMSGJAM.PAS in the mkbbs archive is dated mar 21 1995 17:06

    the mkbbs archive is called MKSRC001.ZIP dated aug 9 1995

    it wasn't long after this that mark pretty much disappeared from sight...

    )\/(ark


    * Origin: (1:3634/12)
  • From Björn Felten@2:203/2 to Scott Little on Sun Jul 11 05:11:26 2004
    Despite a bugfix on this very subject from 1.02 to 1.03,

    Those all seems to be fixed in the 1.05 version I have. I also have 1.06, but that one is always 'unable to open messagebase' for some reason that I haven't bothered to look for.


    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    Hmmm... Why not just delete the '=' sign? :)

    There are some bugs in MkMsgCvt, that I've tracked down to the JAM part, since all works fine to and fro any combination of msg-bases, just not from MSG
    to JAM. After a couple of hundred msgs (different on different "folders", but always on the same msg (usually, but not always, some big msg) in the same folder, the program crashes with a run-time error 216. Going MSG->Squish->JAM works. Really strange bug. Plus of course the S-B lines are added to the msg-text -- might be a correlated bug, but since it seems to be impossible to do any serious debugging on the package, it's hard to find the bug.

    ---
    * Origin: news://felten.dyndns.org (2:203/2)
  • From Björn Felten@2:203/2 to Scott Little on Sun Jul 11 05:16:36 2004
    ((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

    Why? Will you be around Mars 1st 2100 and listen to the complaints? :)

    And unixtime will be broken long before that anyway. 2038 for those that use
    unsigned longint.

    ---
    * Origin: news://felten.dyndns.org (2:203/2)
  • From mark lewis@1:3634/12 to Björn Felten on Sun Jul 11 15:09:52 2004
    Despite a bugfix on this very subject from 1.02 to 1.03,

    Those all seems to be fixed in the 1.05 version I have. I
    also have 1.06, but that one is always 'unable to open
    messagebase' for some reason that I haven't bothered to look
    for.

    its not anything in the 1.06 code as i use it here as designed... in fact, my stuff even goes so far as to create the necessary directories and files if they
    don't exist ;)

    Change
    If JM^.TxtSubChars <= TxtSubBufSize Then
    Into
    If JM^.TxtSubChars <= TxtSubBufSize-1 Then

    Hmmm... Why not just delete the '=' sign? :)

    haha... that would have worked, too... but its not necessary that i've been able to tell...

    There are some bugs in MkMsgCvt, that I've tracked down to
    the JAM part, since all works fine to and fro any combination

    msgcvt was just something tossed together to show using the message libraries as a blackbox... the problem isn't in mkmsgcvt but in the library or the compiler...

    of msg-bases, just not from MSG to JAM. After a couple of
    hundred msgs (different on different "folders", but always on
    the same msg (usually, but not always, some big msg) in the
    same folder, the program crashes with a run-time error 216.

    216? that's not even listed in my TP6 reference stuff... are you sure about that? i just looked...

    [time passes]

    ahh... just looked in BP7 and see that that's a GPF... hummm... sounds like an errant pointer trying to access memory outside its allocation...

    Going MSG->Squish->JAM works. Really strange bug. Plus of
    course the S-B lines are added to the msg-text -- might be a
    correlated bug, but since it seems to be impossible to do any
    serious debugging on the package, it's hard to find the bug.

    paths should done be using the dokludgeln when writting them to the base... seenbys should be done using dokludgeln, too, but they are not...

    ie: hacked together, untested... possibly add to dokludgeln section...

    Else If Copy(Str,1,7) = 'SEEN-BY' Then
    Begin
    TmpStr := StripLead(Copy(Str,8,255),':');
    TmpStr := StripBoth(TmpStr,' ');
    AddSubField(2001, TmpStr);
    End

    and i see what appears to be an error in MsgStartUp (for reading JAM bases) in that seenbys are prefixed with a ^A when they shouldn't be... at least, not if they are going into PKT files... in any case, in JAM bases, seenbys are code 2001 as shown in the above modified snippet from dokludgeln... doing the seenbys properly needs to be built in the same manner as doing the path line except without the leading ^A character...


    hummm... guess i'll have to dig in and write some JAM reading code...

    what's wierd is that JAM is apparently the only message base format that takes special care with control lines... to all the others, its simply a string of text...

    its been a long while since i've dug into this stuff ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Björn Felten on Sun Jul 11 15:11:26 2004
    ((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

    Why? Will you be around Mars 1st 2100 and listen to the
    complaints? :)

    why leave buggy legacy code laying around for others to use?

    And unixtime will be broken long before that anyway. 2038
    for those that use unsigned longint.

    that depends on how big a longint is in the compilers being used at the time ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From Sean Dennis@1:11/200 to Dan Egli on Sun Jul 11 13:13:00 2004
    *** Quoting Dan Egli from a message to mark lewis ***

    if Maarten is even still around anymore. Haven't heard from him in
    the echo for over a year I think.

    He is around, but he is working full-time and doesn't develop EleBBS much anymore. Maarten is hard to get hold of unless you email him.

    --Sean

    --- Telegard/2 v3.09.g2-sp4/mL
    * Origin: Outpost BBS - outpostbbs.us (1:11/200)
  • From Sean Dennis@1:11/200 to Dan Egli on Sun Jul 11 13:16:16 2004
    *** Quoting Dan Egli from a message to mark lewis ***

    and RemoteAccess allwere abandoned by their author. Yes Telegard and
    RA were picked up again, but they also seem to have been dropped
    again. I'm determined to not let that happen to EleBBS untill no one

    Tim Strike is still around, however, he has a real life and things to attend to, so TG got put to the side. We're hoping that he either releases the source
    code or fixes a few things in TG before he disappears again. ;)

    On a side node, Roland de Graff, the author of VBBS/VADV, has suddenly resurfaced. There's discussion going on about VADV's further development, but I don't know anything else about that.

    Anyhow, I'll quit being OT now. ;)

    --Sean

    --- Telegard/2 v3.09.g2-sp4/mL
    * Origin: Outpost BBS - outpostbbs.us (1:11/200)
  • From Roelof Beverdam@2:280/5218 to Björn Felten on Sun Jul 11 09:25:28 2004
    function IsLeapYear;
    begin
    IsLeapYear := (Source and 3 = 0)
    end;

    This cannot be exactly correct, can it?

    Cheers,
    Roelof Beverdam

    --- Dutchie V3.10.11
    * Origin: The Beaver's Nest (2:280/5218)
  • From Björn Felten@2:203/2 to Roelof Beverdam on Wed Jul 14 02:18:10 2004
    function IsLeapYear;
    begin
    IsLeapYear := (Source and 3 = 0)
    end;

    This cannot be exactly correct, can it?

    For the entire, expected lifespan of any Pascal program, with a huge margin and then some, yes I think it is. :)

    ---
    * Origin: news://felten.dyndns.org (2:203/2)
  • From Wayne Steele@3:633/690 to Scott Little on Sat Jul 17 19:25:00 2004
    Hi Scott,

    Line 1490: Change BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
    Into BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

    The EleBBS /mkmsg/mkmsgjam.pas has no record of blockwrite :(

    Any ideas?

    Lata,
    zomorf badnewsbbs@westnet.com.au ICQ: 12489905
    http ftp telnet://badnews.bbs.us & badnewsbbs.darktech.org


    ---
    * Origin: Come & Visit for a Kick@ss EleBBS & EleWEB BBS (3:633/690)
  • From Scott Little@3:712/848 to Wayne Steele on Mon Jul 19 09:37:44 2004
    [ 17 Jul 04 18:25, Wayne Steele wrote to Scott Little ]

    Line 1490: Change BlockWrite(JM^.IdxFile, JamIdx^,
    JamIdxBufSize); Into BlockWrite(JM^.IdxFile, JamIdx^,
    JM^.IdxRead);
    The EleBBS /mkmsg/mkmsgjam.pas has no record of blockwrite :(

    Looks like Maarten replaced it with his FileOBJ unit.


    -- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

    --- GoldED+/W32 1.1.5-31012
    * Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
  • From Dan Egli@1:311/6 to mark lewis on Fri Jul 9 19:26:46 2004
    Hey mark,

    09 Jul 04 17:00, you wrote to me:

    Netiher do I. Which is why I adopted EleBBS sorta. I've had
    three BBS software's I use abandoned, I don't want to make it
    #4. Teleard, TAG, and RemoteAccess all were abandoned by their
    author. Yes Telegard and RA were picked up again, but they
    also seem to have been dropped again. I'm determined to not
    let that happen to EleBBS untill no one is using it, or till I
    just cann't do it anymore.

    understand that... what compiler are you using? what OS' are you
    compiling for? where is the project based?

    Using FreePascal because with it I can compile natively for Win32, DOS16, OS/2 and Linux. I intend to support one of each. I personally don't see the point of
    the DOS/386 port because if you're running a 386 O/S, then you can use the native port for that O/S (i.e. if you're running DOS/386 under Windows, just use the Win32 model).

    -- Dan

    --- FMail/Win32 1.60
    * Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)
  • From Dan Egli@1:311/6 to Björn Felten on Sat Jul 10 18:32:02 2004
    Hey Björn,

    10 Jul 04 18:12, you wrote to mark lewis:

    i found the unix2norm routine... its not anything like
    the stuff i use...

    Here's one that I (and several others) have used for more than ten years now. Take it or leave it. :)

    - = * = -

    unit UnixUtil;

    I will (and did!) take it! Thanks!

    -- Dan

    --- FMail/Win32 1.60
    * Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)
  • From mark lewis@1:3634/12 to Björn Felten on Fri Jan 7 20:44:04 2005
    [[ major apologies... this should have left here back in July but was inadvertently left locked in my base... better late than never, eh? ]]


    in JAM bases, seenbys are code 2001

    reference the JAM specs for this...

    CONST
    JAMSFLD_OADDRESS = 0;
    JAMSFLD_DADDRESS = 1;
    JAMSFLD_SENDERNAME = 2;
    JAMSFLD_RECVRNAME = 3;
    JAMSFLD_MSGID = 4;
    JAMSFLD_REPLYID = 5;
    JAMSFLD_SUBJECT = 6;
    JAMSFLD_PID = 7;
    JAMSFLD_TRACE = 8;
    JAMSFLD_ENCLFILE = 9;
    JAMSFLD_ENCLFWALIAS = 10;
    JAMSFLD_ENCLFREQ = 11;
    JAMSFLD_ENCLFILEWC = 12;
    JAMSFLD_ENCLINDFILE = 13;
    JAMSFLD_EMBINDAT = 1000;
    JAMSFLD_FTSKLUDGE = 2000;
    JAMSFLD_SEENBY2D = 2001;
    JAMSFLD_PATH2D = 2002;
    JAMSFLD_FLAGS = 2003;
    JAMSFLD_TZUTCINFO = 2004;
    JAMSFLD_UNKNOWN = $ffff;

    an additional note that i see that the mkjam stuff also doesn't do anything with the TZUTC stuff, either... that's a 2004 in the above... i see some mods coming to the stuff that i do here, ;)

    )\/(ark


    * Origin: (1:3634/12)
  • From mark lewis@1:3634/12 to Björn Felten on Fri Jan 7 20:47:14 2005
    an additional note that i see that the mkjam stuff also
    doesn't do anything with the TZUTC stuff, either... that's a
    2004 in the above... i see some mods coming to the stuff that
    i do here, ;)

    following up to that message that was locked and just released... i made those mods back then and everything seems to work properly... the only problems i've seen are that some programs don't recognise those codes or don't display the data in them... nevertheless, i've implemented them in my version of the mkmsgsrc jam code and am have been using them since July of '04 with no ill effects...

    )\/(ark


    * Origin: (1:3634/12)