• Feature request

    From mark lewis@1:3634/12.73 to Michiel van der Vlist on Tuesday, January 26, 2016 23:28:56

    26 Jan 16 21:31, you wrote to Wilfred van Velzen:

    When I started using binkd one of the first things that did strike me
    as odd (and akward), is that it has no default for the config file.
    Binkd was the first application (and so far the only) on my system
    that requires the config file to always be specified explicitly in the command line.

    Every other application I have ever used and that can use more than
    one config file has a default. Except binkd...

    they say that binkd is ahead of its time ;) O:)

    )\/(ark

    ... Sailors curse the rain that farmers prayed for in vain.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Michiel van der Vlist on Tuesday, January 26, 2016 23:30:16

    26 Jan 16 21:26, you wrote to me:

    the only times i've used binkd.cfg for my config file name was on
    systems that are/were 8.3 limited... on (my) *nix systems, the
    preferred extension is .conf or .config which should be compatible
    with today's winwhatever systems... i'm not sure how i feel about
    having a default configuration file name... wouldn't it be easier to
    write yourself a script that you feed the address to??

    If writing small scripts and using long file names is your preferrerd method of doing things, than by all means use that method. My request
    for a default binkd.cfg does not stop you from doing things your way
    does it?

    why did you respond to my post, which was the same as others' WRT using a script file, so differently???

    )\/(ark

    ... Coca-Cola contains neither coca nor cola.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Tuesday, January 26, 2016 23:32:14

    26 Jan 16 22:32, you wrote to Michiel van der Vlist:

    MvdV>> Every other application I have ever used and that can use more than
    MvdV>> one config file has a default. Except binkd...

    I found it odd too. In linux most applications with a config file
    asume it is in some default location unless otherwise specified.

    how new to *nix systems are we??

    )\/(ark

    ... Let the illuminati do your thinking for you whilst you merely obey.
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Tuesday, January 26, 2016 23:36:02

    26 Jan 16 21:57, you wrote to Michiel van der Vlist:

    MvdV>> Because I do not like to contaminate my system with many small
    MvdV>> batch files. I prefer the method with uses defaults.

    Then make one binkd.bat make sure it is found before the before the binkd.exe and put all your default whishes in that batchfile, and
    allow the defaults to be overwritten by comand line parameters. Your choise is to contaminate the main source with your default whishes and that is o.k. because you donot see it.

    Ah, so i am not the only one! ;)

    )\/(ark

    ... I'm not nearly as think as you confused I am!
    ---
    * Origin: (1:3634/12.73)
  • From Wilfred van Velzen@2:280/464.112 to mark lewis on Wednesday, January 27, 2016 08:50:44
    Hi mark,

    On 26 Jan 16 23:32, mark lewis wrote to Wilfred van Velzen:
    about: "Feature request":

    MvdV>>> Every other application I have ever used and that can use more
    MvdV>>> than
    MvdV>>> one config file has a default. Except binkd...

    I found it odd too. In linux most applications with a config file
    asume it is in some default location unless otherwise specified.

    how new to *nix systems are we??

    I don't understand the question...

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Pavel Gulchouck@2:463/68 to Michiel van der Vlist on Wednesday, January 27, 2016 12:36:32
    Hi Michiel!

    26 Jan 16, Michiel van der Vlist ==> Binkd team:

    MvdV> I often poll a node by starting binkd in another window by typing:

    MvdV> binkd -nP<node number> binkd.cfg

    MvdV> While it is good that binkd can be started with an alternate configuration, it would save me a lot of typing if
    MvdV> binkd.cfg in the current directory would be the default.

    I agree, default path for config file and option for override it is common practice.
    I'll merge pull-request with this feature (and with backward compatibility) if anybody make it.

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by configure (/usr/local/etc by default), then ~/binkd.conf.
    Not sure about win32. May be current directory is reasonable choice.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Wilfred van Velzen@2:280/464.112 to Pavel Gulchouck on Wednesday, January 27, 2016 13:11:55
    Hi Pavel,

    On 27 Jan 16 12:36, Pavel Gulchouck wrote to Michiel van der Vlist:
    about: "Feature request":

    I agree, default path for config file and option for override it is
    common practice. I'll merge pull-request with this feature (and with backward compatibility) if anybody make it.

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by configure (/usr/local/etc by default), then ~/binkd.conf.

    Not sure about win32. May be current directory is reasonable choice.

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\ is a good place.


    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Wednesday, January 27, 2016 15:42:40
    Hello Wilfred,

    Wednesday January 27 2016, Wilfred van Velzen wrote to Pavel Gulchouck:

    I agree, default path for config file and option for override it
    is common practice. I'll merge pull-request with this feature
    (and with backward compatibility) if anybody make it.

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir
    set by configure (/usr/local/etc by default), then ~/binkd.conf.

    Not sure about win32. May be current directory is reasonable
    choice.

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\ is
    a good place.

    What is CSIDL_COMMON_APPDATA?

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Wilfred van Velzen@2:280/464 to Michael Dukelsky on Wednesday, January 27, 2016 14:00:16
    Hi Michael,

    On 2016-01-27 15:42:40, you wrote to me:

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
    is a good place.

    What is CSIDL_COMMON_APPDATA?

    Should I explain how google works? ;)

    Bye, Wilfred.

    --- FMail-W32-1.69.12.144-B20160109
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Wednesday, January 27, 2016 13:33:40
    Hello Pavel,

    On Wednesday January 27 2016 12:36, you wrote to me:

    MvdV>> While it is good that binkd can be started with an alternate
    MvdV>> configuration, it would save me a lot of typing if binkd.cfg in
    MvdV>> the current directory would be the default.

    I agree, default path for config file and option for override it is
    common practice.

    Thanks.

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir set
    by configure (/usr/local/etc by default), then ~/binkd.conf.

    If that is common practisefor linux, that is fine with me.

    Not sure about win32. May be current directory is reasonable choice.

    Current directory is common practise for command line utilities, although some use the directory where the .exe is located as the default. It is an inheretance from DOS really.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Wednesday, January 27, 2016 13:37:36
    Hello Wilfred,

    On Wednesday January 27 2016 13:11, you wrote to Pavel Gulchouck:

    Not sure about win32. May be current directory is reasonable
    choice.

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\ is
    a good place.

    Arggh! Who can remember that? I will never find it back if it is plced there. I
    don't even have such a directory on my system. Not on the C: drive and not on the D: drive where my Fido stuff is located.

    Also: In Windows, names of system directories are different for different language versions. On my German version of Windows, the directory where programms are found is called "Programme". There is another one called "Documente und Einstellungen". Etc, etc.



    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Kees van Eeten@2:280/5003.4 to Wilfred van Velzen on Wednesday, January 27, 2016 14:10:16
    Hello Wilfred!

    27 Jan 16 14:00, you wrote to Michael Dukelsky:

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
    is a good place.

    What is CSIDL_COMMON_APPDATA?

    Should I explain how google works? ;)

    What is google? I cannot find a reference in the FTSC documents.

    Kees

    --- GoldED+/LNX 1.1.5
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Wednesday, January 27, 2016 14:07:22
    Hi Michiel,

    On 2016-01-27 13:33:40, you wrote to Pavel Gulchouck:

    Not sure about win32. May be current directory is reasonable choice.

    MvdV> Current directory is common practise for command line utilities, although
    MvdV> some use the directory where the .exe is located as the default. It is an
    MvdV> inheretance from DOS really.

    That's DOS practise! Not WIN32! On modern windows users don't have write access
    to subdirectories of C:\Program Files[ (x86)]\, where programs are normally installed!

    Bye, Wilfred.

    --- FMail-W32-1.69.12.144-B20160109
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464.112 to Michiel van der Vlist on Wednesday, January 27, 2016 14:26:37
    Hi Michiel,

    On 2016-01-27 13:37:36, you wrote to me:

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
    is a good place.

    MvdV> Arggh! Who can remember that? I will never find it back if it is
    MvdV> plced there. I don't even have such a directory on my system. Not on
    MvdV> the C: drive and not on the D: drive where my Fido stuff is located.

    MvdV> Also: In Windows, names of system directories are different for
    MvdV> different language versions. On my German version of Windows, the
    MvdV> directory where programms are found is called "Programme". There is
    MvdV> another one called "Documente und Einstellungen". Etc, etc.

    I had hoped people used google for this! ;)

    CSIDL_COMMON_APPDATA is a constant you feed to the windows api function SHGetFolderPath(), which gives you back "The file system directory that contains application data for all users". On XP this is "C:\Documents and Settings\All Users\Application Data" (or equivalent for different languages). On Windows 7 this is C:\ProgramData\. According to microsoft standards, an installer (or program) is supposed to create/use a subdirectory structure in there like: "\company\product", and use that for it's common, non user specific, data.

    Please don't shoot the messenger! ;)

    Bye, Wilfred.


    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Wilfred van Velzen@2:280/464.112 to Kees van Eeten on Wednesday, January 27, 2016 14:24:17
    Hi Kees,

    On 27 Jan 16 14:10, Kees van Eeten wrote to Wilfred van Velzen:
    about: "Feature request":

    Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
    is a good place.

    What is CSIDL_COMMON_APPDATA?

    Should I explain how google works? ;)

    What is google? I cannot find a reference in the FTSC documents.

    Someone should write a fsp ! ;)

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Wednesday, January 27, 2016 16:36:14
    Hello Wilfred,

    Wednesday January 27 2016, Wilfred van Velzen wrote to Michael Dukelsky:

    Besides the current dir, probably:
    CSIDL_COMMON_APPDATA\Fido\binkd\ is a good place.

    What is CSIDL_COMMON_APPDATA?

    Should I explain how google works? ;)

    Do you really know HOW google works? I thought it was their corporate secret.

    I see you prefer answering with a question. Why do you think ANYTHING\Fido\binkd\ is a good place? Only because you use it? I have no such a
    directory in my fidonet box.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Wednesday, January 27, 2016 16:40:44
    Hello Wilfred,

    Wednesday January 27 2016, Wilfred van Velzen wrote to Michiel van der Vlist:

    CSIDL_COMMON_APPDATA is a constant you feed to the windows api
    function SHGetFolderPath()

    IMHO it is not a good idea to use a Windows API function in a multi-platform project.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Björn Felten@3:640/384 to Pavel Gulchouck on Thursday, January 28, 2016 00:25:46
    Not sure about win32. May be current directory is reasonable choice.

    Absolutely! Current as in the directory where your EXE-file is located.

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Michael Dukelsky@2:5020/1042 to Björn Felten on Wednesday, January 27, 2016 17:29:04
    Hello Björn,

    Thursday January 28 2016, Björn Felten wrote to Pavel Gulchouck:

    Not sure about win32. May be current directory is reasonable
    choice.

    Absolutely! Current as in the directory where your EXE-file is
    located.

    Sorry, but I cannot agree. It is not good to have configuration files and executables in one directory. Microsoft used that bad practise in Windows 9x, but later they abandoned it.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Bjrn Felten@3:640/384 to Michael Dukelsky on Thursday, January 28, 2016 00:50:42
    Sorry, but I cannot agree. It is not good to have configuration files
    and executables in one directory. Microsoft used that bad practise in Windows 9x, but later they abandoned it.

    Strange. It seems to work for every other program I use on my XP-boxes as well as on my Win7-boxes.

    I like to have everything related to a program at one single place. What's so bad about it?

    Yeah, well, YMMV of course...




    ..

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Tommi Koivula@2:221/0 to Michael Dukelsky on Wednesday, January 27, 2016 17:09:38
    27 Jan 16 17:29, Michael Dukelsky wrote to Bjorn Felten:

    Absolutely! Current as in the directory where your EXE-file is
    located.

    Sorry, but I cannot agree. It is not good to have configuration files
    and executables in one directory. Microsoft used that bad practise in Windows 9x, but later they abandoned it.

    In OS/2 I still prefer the directory where the executable is located. Also the husky way would be ok, use environment variable for pointing the config file.

    I have no problem with the current way; no default.

    'Tommi

    --- GoldED+/EMX 1.1.5-b20151130
    * Origin: =========================================== (2:221/0)
  • From Wilfred van Velzen@2:280/464.112 to Michael Dukelsky on Wednesday, January 27, 2016 16:14:09
    Hi Michael,

    On 27 Jan 16 16:36, Michael Dukelsky wrote to Wilfred van Velzen:
    about: "Feature request":

    I see you prefer answering with a question. Why do you think ANYTHING\Fido\binkd\ is a good place? Only because you use it? I have
    no such a directory in my fidonet box.

    (See my answer to Michiel.) Because it's a windows standard.

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Wilfred van Velzen@2:280/464.112 to Michael Dukelsky on Wednesday, January 27, 2016 16:29:13
    Hi Michael,

    On 27 Jan 16 16:40, Michael Dukelsky wrote to Wilfred van Velzen:
    about: "Feature request":

    CSIDL_COMMON_APPDATA is a constant you feed to the windows api
    function SHGetFolderPath()

    IMHO it is not a good idea to use a Windows API function in a multi-platform project.

    The binkd source already is full of "#ifdef WIN32"'s ...

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Björn Felten@3:640/384 to Tommi Koivula on Thursday, January 28, 2016 01:32:50
    I have no problem with the current way; no default.

    I have the following in my binkd.cfg:

    #
    # Include a file
    #
    include binkd.inc
    include pass.inc

    And then:

    #
    # Perl DLL file (only matters if compiled with PERLDL=1 for Win32)
    #
    perl-dll perl510.dll

    All three seem to be found without problem. In the current directory.

    And having a special version of perl510.dll in the binkd directory makes it easier to prevent any collisions due to me having another version in Windows' dll-directory...



    ..

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Michael Dukelsky@2:5020/1042 to Bj?rn Felten on Wednesday, January 27, 2016 18:11:30
    Hello Bj?rn,

    Thursday January 28 2016, Bj?rn Felten wrote to Michael Dukelsky:

    Sorry, but I cannot agree. It is not good to have configuration
    files and executables in one directory. Microsoft used that bad
    practise in Windows 9x, but later they abandoned it.

    Strange. It seems to work for every other program I use on my
    XP-boxes as well as on my Win7-boxes.

    I like to have everything related to a program at one single place. What's so bad about it?

    From the security point of view it is bad to run programs from an account with administrative rights because in that case the possibility to get some malware is higher. Therefore they advise to run programs from a restricted account. Executables are stored in Program Files but if you work in a restricted account, you will not be able to write to Program Files. It is done on purpose.
    If you for example click by accident on a reference in a fishing e-mail message
    and download and run some malware while you work in a restricted account, the malware will not be able to infect the executables in Program Files. That is why application store their data in %APPDATA% and not in %ProgramFiles%. You can easily edit files there without running your editor as administrator.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Björn Felten@3:640/384 to Michael Dukelsky on Thursday, January 28, 2016 01:52:18
    Executables are stored in Program Files

    Only when installed the usual Windows way.

    Binkd isn't "installed" per se, it's just unpacked in a directory of your choice. Big difference...




    ..

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Wednesday, January 27, 2016 16:32:00
    Hello Wilfred,

    On Wednesday January 27 2016 14:07, you wrote to me:

    MvdV>> Current directory is common practise for command line
    MvdV>> utilities, although some use the directory where the .exe is
    MvdV>> located as the default. It is an inheretance from DOS really.

    That's DOS practise! Not WIN32! On modern windows users don't have
    write access to subdirectories of C:\Program Files[ (x86)]\, where programs are normally installed!

    The M$ way may be a good idea to follow for GUI programmes, where the user never has to access the configuration files directly. For CLI programmes where the configuration file is a text file that the user must edit with a text editor it is a nightmare to have the config file hidden that deep.

    It may be the DOS way, but Fidonet was developed for DOS and still follows the DOS way in many things. For CLI programmes that is much easier to work with.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Wednesday, January 27, 2016 16:53:58
    Hello Wilfred,

    On Wednesday January 27 2016 14:26, you wrote to me:

    CSIDL_COMMON_APPDATA is a constant you feed to the windows api
    function SHGetFolderPath(), which gives you back "The file system directory that contains application data for all users". On XP this is "C:\Documents and Settings\All Users\Application Data" (or equivalent
    for different languages). On Windows 7 this is C:\ProgramData\.
    According to microsoft standards, an installer (or program) is
    supposed to create/use a subdirectory structure in there like: "\company\product", and use that for it's common, non user specific,
    data.

    I do not consider it a good idea to follow that practise for Command Line programmes. In particular for binkd that has no setup programme and the user has to edit the config file with a text editor.

    Please don't shoot the messenger! ;)

    You are not going to tell me that you actually have your binkd.cfg in CSIDL_COMMON_APPDATA\Fido\binkd\ and that you go there with a text editor to chage it are you?

    You can't be serious.

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Michael Dukelsky on Wednesday, January 27, 2016 16:42:17
    Hello Michael,

    On Wednesday January 27 2016 17:29, you wrote to Bjrn Felten:

    Absolutely! Current as in the directory where your EXE-file is
    located.

    Sorry, but I cannot agree. It is not good to have configuration files
    and executables in one directory.

    Why? Just because M$ says so?

    Microsoft used that bad practise in Windows 9x, but later they
    abandoned it.

    Fideonet is not Micrsoft. What is good for Microsoft may not be good for Fidonet.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Björn Felten on Wednesday, January 27, 2016 16:44:21
    Hello Björn,

    On Thursday January 28 2016 00:50, you wrote to Michael Dukelsky:

    I like to have everything related to a program at one single place. What's so bad about it?

    Same here. All the fidonet stuff is on the D: drive in subdirectories with the .exe and the acompanying configuration file(s) in the same subdirectory. That may be the DOS way, but for Fidonet stuff that is all CLI this works best for me.

    Yeah, well, YMMV of course...

    Of course...

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michael Dukelsky@2:5020/1042 to Tommi Koivula on Wednesday, January 27, 2016 19:04:38
    Hello Tommi,

    Wednesday January 27 2016, Tommi Koivula wrote to Michael Dukelsky:

    Absolutely! Current as in the directory where your EXE-file
    is located.

    Sorry, but I cannot agree. It is not good to have configuration
    files and executables in one directory. Microsoft used that bad
    practise in Windows 9x, but later they abandoned it.

    In OS/2 I still prefer the directory where the executable is located.
    Also the husky way would be ok, use environment variable for pointing
    the config file.

    Using an environment variable would be much better than any directory hardwired
    in the executable.

    I have no problem with the current way; no default.

    Neither do I.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Wednesday, January 27, 2016 19:07:10
    Hello Wilfred,

    Wednesday January 27 2016, Wilfred van Velzen wrote to Michael Dukelsky:

    I see you prefer answering with a question. Why do you think
    ANYTHING\Fido\binkd\ is a good place? Only because you use it? I
    have no such a directory in my fidonet box.

    (See my answer to Michiel.) Because it's a windows standard.

    No, Wilfred. Fido\binkd is not a Windows standard. :)

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to Björn Felten on Wednesday, January 27, 2016 19:11:52
    Hello Björn,

    Thursday January 28 2016, Björn Felten wrote to Michael Dukelsky:

    Executables are stored in Program Files

    Only when installed the usual Windows way.

    Binkd isn't "installed" per se, it's just unpacked in a directory
    of your choice. Big difference...

    Use a standard way and make Program Files a directory of your choice. :)

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michiel van der Vlist@2:280/5555 to Michael Dukelsky on Wednesday, January 27, 2016 17:04:52
    Hello Michael,

    On Wednesday January 27 2016 18:11, you wrote to Bj?rn Felten:

    Executables are stored in Program Files but if you work in a
    restricted account, you will not be able to write to Program Files. It
    is done on purpose. If you for example click by accident on a
    reference in a fishing e-mail message and download and run some
    malware while you work in a restricted account, the malware will not
    be able to infect the executables in Program Files. That is why application store their data in %APPDATA% and not in %ProgramFiles%.

    Oh, c'mon, when was the last time a _Fidonet_ executable was infected by malware by clicking on a link in a fishing mail?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Bjrn Felten@3:640/384 to Michael Dukelsky on Thursday, January 28, 2016 02:37:43
    Use a standard way and make Program Files a directory of your choice. :)

    By what standard is that?

    I've always had the programs I just unpack and then run (as opposed to the standard Windows install) in a dedicated directory. With all the accompanying files collected in the same place.

    And that usually goes for my linux boxes too. I just hate being forced to search for the configs all over the place.





    ..

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Björn Felten@3:640/384 to Michiel van der Vlist on Thursday, January 28, 2016 02:48:22
    MvdV> Oh, c'mon, when was the last time a _Fidonet_ executable was infected by
    MvdV> malware by clicking on a link in a fishing mail?

    Besides, isn't 'Windows security' an oxymoron by itself? 8-)






    ..

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Wednesday, January 27, 2016 18:30:25
    Hi,

    On 2016-01-27 16:53:58, Michiel van der Vlist wrote to Wilfred van Velzen:
    about: "Feature request":

    MvdV> You are not going to tell me that you actually have your binkd.cfg
    MvdV> in CSIDL_COMMON_APPDATA\Fido\binkd\ and that you go there with a
    MvdV> text editor to chage it are you?

    I only use binkd on windows as a point to make ad hoc connections to my "boss" node. If I would run binkd on windows as a daemon, I would probably do it differently. And might have put it there. But then I would probably also made some kind of shortcut in TotalCommander to go to that directory in "1 click". ;)

    But more likely I would do it the linux way and create a \fido\bin directory for executables and a \fido\etc for configuration files.

    Bye, Wilfred.


    --- FMail-W32-1.69.12.144-B20160109
    * Origin: Native IPv6 connectable node (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Wednesday, January 27, 2016 18:27:29
    Hi,

    On 2016-01-27 16:42:17, Michiel van der Vlist wrote to Michael Dukelsky:
    about: "Feature request":

    Microsoft used that bad practise in Windows 9x, but later they
    abandoned it.

    MvdV> Fideonet is not Micrsoft. What is good for Microsoft may not be good for
    MvdV> Fidonet.

    If you want to stay compatible with future windows versions, it might be a good
    idea to follow microsoft best practice guide lines!

    Anyway one doesn't exclude the other. Binkd could check both the windows default directory and the current directory for it's configuration file, so everybody would be happy! ;)

    Bye, Wilfred.


    --- FMail-W32-1.69.12.144-B20160109
    * Origin: Native IPv6 connectable node (2:280/464)
  • From Stephen Hurd@1:103/1 to Michael Dukelsky on Wednesday, January 27, 2016 21:00:01
    Re: Feature request
    By: Michael Dukelsky to Wilfred van Velzen on Wed Jan 27 2016 04:40 pm

    CSIDL_COMMON_APPDATA is a constant you feed to the windows api
    function SHGetFolderPath()

    IMHO it is not a good idea to use a Windows API function in a multi-platform project.

    If you're behaving differently for Windows any, there's no reason not to.
    --- SBBSecho 2.32-FreeBSD
    * Origin: BBSDev.net - The BBS Developers Network (1:103/1)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Wednesday, January 27, 2016 14:36:00

    27 Jan 16 16:14, you wrote to Michael Dukelsky:

    I see you prefer answering with a question. Why do you think
    ANYTHING\Fido\binkd\ is a good place? Only because you use it? I have
    no such a directory in my fidonet box.

    (See my answer to Michiel.) Because it's a windows standard.

    wouldn't it be better to use %APPDATA%/FTN/binkd? %APPDATA% because... well, it
    is winwhatever... FTN because fidonet is not the only FTN and there are many folks in other FTNs that are not in fidonet and never will be... FTN covers all
    FTNs ;)

    )\/(ark

    ... What was once a hobby is now an obsession!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Michiel van der Vlist on Wednesday, January 27, 2016 14:23:14

    27 Jan 16 17:04, you wrote to Michael Dukelsky:

    Oh, c'mon, when was the last time a _Fidonet_ executable was infected
    by malware by clicking on a link in a fishing mail?

    really?? /ANY/ executable can be infected or affected by numerous means... how many sysops do you think will publically admit that their system got infested with malware?

    )\/(ark

    ... Grow up?? I never finished my _first_ childhood!
    ---
    * Origin: (1:3634/12.73)
  • From mark lewis@1:3634/12.73 to Pavel Gulchouck on Wednesday, January 27, 2016 14:27:44

    27 Jan 16 12:36, you wrote to Michiel van der Vlist:

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by configure (/usr/local/etc by default), then ~/binkd.conf.

    perhaps the second place to look would be better known as ~/.binkd/binkd.conf or ~/.ftn/binkd.conf??

    me? my binkd is built for private use in my personal home directory so all of it resides within ~/... spcifically, i use

    --prefix=~/ftn/

    in my script that updates, configures, builds and installs binkd... if there are other users on the system that want or need to use binkd, they can build their own copy ;)

    )\/(ark

    ... According to Descartes, Rush Limbaugh doesn't exist.
    ---
    * Origin: (1:3634/12.73)
  • From Pavel Gulchouck@2:463/68 to mark lewis on Wednesday, January 27, 2016 22:46:50
    Hi mark!

    27 Jan 16, mark lewis ==> Pavel Gulchouck:

    In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by
    configure (/usr/local/etc by default), then ~/binkd.conf.

    perhaps the second place to look would be better known as
    ~/.binkd/binkd.conf or ~/.ftn/binkd.conf??

    It's usual for unix utilities, but I doubt about it's convenient for binkd. binkd is part of fidonet system and I do not think that somebody keep binkd.conf in hidden directory in his home. It's not utility like vim or curl. So, config ~/binkd.conf or ~/etc/binkd.conf is more common - if binkd works from system user "fnet" or "fido" or when user have no root permissions.

    me? my binkd is built for private use in my personal home directory so all
    of it resides within ~/... spcifically, i use

    --prefix=~/ftn/

    in my script that updates, configures, builds and installs binkd... if
    there are other users on the system that want or
    need to use binkd, they can build their own copy ;)

    Sure, sysconfdir should be first place for search binkd.conf.

    configure options:

    --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local]
    [...]
    --sysconfdir=DIR read-only single-machine data [PREFIX/etc]

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Wednesday, January 27, 2016 22:40:37
    Hello Wilfred,

    On Wednesday January 27 2016 18:27, you wrote to me:

    MvdV>> Fideonet is not Micrsoft. What is good for Microsoft may not be
    MvdV>> good for Fidonet.

    If you want to stay compatible with future windows versions, it might
    be a good idea to follow microsoft best practice guide lines!

    If I may want to stay compatible with future windows versions, if... I will cross that bridge when I get to it. For the moment I find the old DOS method far more convenient for command line utilities like binkd.

    Anyway one doesn't exclude the other. Binkd could check both the
    windows default directory and the current directory for it's
    configuration file, so everybody would be happy! ;)

    I can live with that. ;-)


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to mark lewis on Wednesday, January 27, 2016 22:55:20
    Hello mark,

    On Wednesday January 27 2016 14:23, you wrote to me:

    Oh, c'mon, when was the last time a _Fidonet_ executable was
    infected by malware by clicking on a link in a fishing mail?

    really?? /ANY/ executable can be infected or affected by numerous
    means...

    And so in theory a fidonet executable could also be infected. Once the infector
    gets past the defences already in place.

    In theory an intruder can get into my bathroom and use my toilet without permission. Once he gets into my house.

    In practice I weigh the risk against the inconvenience. There is no big lock on
    the door of my toilet. Anyone who gets in the house can use the toilet. I find it far too inconvenient for myself to have an extra barrier there.

    So I ask again: when was the last time a _Fidonet_ executable was infected by malware by clicking on a link in a fishing mail?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464.112 to mark lewis on Thursday, January 28, 2016 09:08:16
    Hi mark,

    On 27 Jan 16 14:36, mark lewis wrote to Wilfred van Velzen:
    about: "Feature request":

    wouldn't it be better to use %APPDATA%/FTN/binkd? %APPDATA% because... well, it is winwhatever...

    That's equivalent to using CSIDL_APPDATA with SHGetFolderPath().

    But when you are running binkd as a daemon I don't think you want to use a users private appdata directory for this, but maybe you should?

    CSIDL_COMMON_APPDATA is equivalent to %ALLUSERSPROFILE%. But from Windows Vista
    and higher you are supposed to use %ProgramData%. So using the environment variable is less standardized. But that's true for the CSIDL_ constants too, they are replaced by FOLDERID_ constants from Vista and onwards...

    FTN because fidonet is not the only FTN and there are many folks in
    other FTNs that are not in fidonet and never will be... FTN covers all FTNs ;)

    Sure, but what is the F in FTN stand for? ;)

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Wilfred van Velzen@2:280/464.112 to Michiel van der Vlist on Thursday, January 28, 2016 09:27:10
    Hi Michiel,

    On 27 Jan 16 22:40, Michiel van der Vlist wrote to Wilfred van Velzen:
    about: "Feature request":

    MvdV>>> Fideonet is not Micrsoft. What is good for Microsoft may not be
    MvdV>>> good for Fidonet.

    If you want to stay compatible with future windows versions, it might
    be a good idea to follow microsoft best practice guide lines!

    MvdV> If I may want to stay compatible with future windows versions, if... I
    MvdV> will cross that bridge when I get to it. For the moment I find the old
    MvdV> DOS method far more convenient for command line utilities like binkd.

    This is not about your personal preference! ;)

    It's what is convenient (or even necessary) for most future binkd windows users...

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Thursday, January 28, 2016 11:56:14
    Hello Wilfred,

    On Thursday January 28 2016 09:27, you wrote to me:

    This is not about your personal preference! ;)

    Expressing my personal preference of having a default for the name of the config file is what started this thread....

    I am starting to wish I hadn't. It seems I have opened a can of worms...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Thursday, January 28, 2016 12:05:56
    Hi Michiel,

    On 2016-01-28 11:56:14, you wrote to me:

    This is not about your personal preference! ;)

    MvdV> Expressing my personal preference of having a default for the name of the
    MvdV> config file is what started this thread....

    Yes, but this process is about trying to translate to general usefull functionality.

    MvdV> I am starting to wish I hadn't. It seems I have opened a can of
    MvdV> worms...

    I don't think so. This hopefully will lead to some improvements in binkd usefull for everyone in some extend. ;)

    Bye, Wilfred.

    --- FMail-W32-1.69.12.144-B20160109
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Thursday, January 28, 2016 09:52:50

    28 Jan 16 09:08, you wrote to me:

    wouldn't it be better to use %APPDATA%/FTN/binkd? %APPDATA%
    because... well, it is winwhatever...

    That's equivalent to using CSIDL_APPDATA with SHGetFolderPath().

    never heard of that CSIDL thing until you brought it up...

    But when you are running binkd as a daemon I don't think you want to
    use a users private appdata directory for this, but maybe you should?

    wait, what? are you ""stuck"" on one machine, one person? i certainly do not want other folks' mail in my stuff nor do i want mine in their's... they can run their own point or node with or without full bbs if they want and i'll run mine... long gone are the days where one machine is tasked with one job... now those types of things are done per account and machines have numerous accounts... each standing alone and separate from the others...

    )\/(ark

    ... For good clean fun, shower with a friend. Wanna be my friend? ;*)
    ---
    * Origin: (1:3634/12.73)
  • From Björn Felten@3:640/384 to mark lewis on Friday, January 29, 2016 03:38:23
    wait, what? are you ""stuck"" on one machine, one person? i certainly do not want other folks' mail in my stuff nor do i want mine in their's... they can run their own point or node with or without full bbs if they
    want and i'll run mine... long gone are the days where one machine is tasked with one job... now those types of things are done per account
    and machines have numerous accounts... each standing alone and separate from the others...

    I don't know how you start your binkd, but here I have a DOS window reading D:\WINDOWS\system32\cmd.exe in the top bar.

    And all files, other than binkd.cfg, is automatically found by binkd in it's
    current directory.

    Isn't this a storm in a glass of water?

    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Thursday, January 28, 2016 20:56:30
    Hello Wilfred,

    Thursday January 28 2016, Wilfred van Velzen wrote to mark lewis:

    But when you are running binkd as a daemon I don't think you want to
    use a users private appdata directory for this, but maybe you should?

    Please read FAQ 37 where it is explained how to configure binkd to run as a Windows service owned by a restricted user account. Why should one use a common
    directory instead of a private one? I see not a single reason.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20151128
    * Origin: Moscow, Russia (2:5020/1042)
  • From mark lewis@1:3634/12.73 to Björn Felten on Thursday, January 28, 2016 13:59:00

    29 Jan 16 03:38, you wrote to me:

    wait, what? are you ""stuck"" on one machine, one person? i certainly
    do not want other folks' mail in my stuff nor do i want mine in
    their's... they can run their own point or node with or without full
    bbs if they want and i'll run mine... long gone are the days where one
    machine is tasked with one job... now those types of things are done
    per account and machines have numerous accounts... each standing alone
    and separate from the others...

    I don't know how you start your binkd,

    ~/ftn/sbin/binkd -C ~/ftn/etc/binkd.conf

    but here I have a DOS window reading D:\WINDOWS\system32\cmd.exe in
    the top bar.

    that's a cmd window ;)

    And all files, other than binkd.cfg, is automatically found by binkd
    in it's current directory.

    that's fine if that's the way your conf file is set up...

    Isn't this a storm in a glass of water?

    i don't know... i'm fine and happy with binkd the way it stands in this regard...

    my main point above was not liking forcing central system wide directories to be used for all instances of software like binkd... better to use per user copies /unless/ the BOfH decides they want to provide one system wide installation... even then, though, they can specify the desired directories within the conf file... this effectively becomes a "multi-user point system", though, instead of being the traditional "point per user"... having private netmail would not be so easy with everything being shared...

    )\/(ark

    ... Where there's smoke there's pollution. - Neekha
    ---
    * Origin: (1:3634/12.73)
  • From Kurt Weiske@1:218/700 to Bj÷rn Felten on Thursday, January 28, 2016 19:59:04
    Re: Feature request
    By: Bj÷rn Felten to Michael Dukelsky on Thu Jan 28 2016 12:50 am

    I like to have everything related to a program at one single place. What's so bad about it?

    I like being able to back up /etc and /var and get all of the configs in one place.
    --- SBBSecho 2.27-Win32
    * Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)
  • From Wilfred van Velzen@2:280/464.112 to mark lewis on Friday, January 29, 2016 08:42:05
    Hi mark,

    On 28 Jan 16 09:52, mark lewis wrote to Wilfred van Velzen:
    about: "Feature request":

    That's equivalent to using CSIDL_APPDATA with SHGetFolderPath().

    never heard of that CSIDL thing until you brought it up...

    So you are not a certified microsoft developer? (Me neither) ;-)

    But when you are running binkd as a daemon I don't think you want to
    use a users private appdata directory for this, but maybe you should?

    wait, what? are you ""stuck"" on one machine, one person? i certainly do not want other folks' mail in my stuff nor do i want mine in their's... they can run their own point or node with or without full bbs if they want and i'll run mine... long gone are the days where one machine is tasked with one job... now those types of things are done per account and machines have numerous accounts... each standing alone and separate from the others...

    You do have a valid point, although I think your usecase is very unlikely. But what does happen is that sysops with more than 1 nodenumber (sometimes in fidonet, sometimes in different othernets), want to run more than 1 instance of
    binkd with seperate configurations. If they run those in different user accounts, you don't want to have those binkd instances look in the same location for their default configuration file. So although binkd is a server application and can be run as a daemon, APPDATA might be a good place for the default binkd configuration file location...

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From Wilfred van Velzen@2:280/464.112 to Michael Dukelsky on Friday, January 29, 2016 08:50:17
    Hi Michael,

    On 28 Jan 16 20:56, Michael Dukelsky wrote to Wilfred van Velzen:
    about: "Feature request":

    But when you are running binkd as a daemon I don't think you want to
    use a users private appdata directory for this, but maybe you should?

    Please read FAQ 37 where it is explained how to configure binkd to run as a Windows service owned by a restricted user account. Why should one use a common directory instead of a private one? I see not a single reason.

    Indeed, I changed my mind... ;)

    Wilfred.

    --- FMail-W32-1.69.10.141-B20151003
    * Origin: point@work (2:280/464.112)
  • From mark lewis@1:3634/12.73 to Wilfred van Velzen on Friday, January 29, 2016 08:29:40

    29 Jan 16 08:42, you wrote to me:

    But when you are running binkd as a daemon I don't think you want to
    use a users private appdata directory for this, but maybe you
    should?

    wait, what? are you ""stuck"" on one machine, one person? i certainly
    do not want other folks' mail in my stuff nor do i want mine in
    their's... they can run their own point or node with or without full
    bbs if they want and i'll run mine... long gone are the days where
    one machine is tasked with one job... now those types of things are
    done per account and machines have numerous accounts... each standing
    alone and separate from the others...

    You do have a valid point, although I think your usecase is very unlikely.

    maybe, maybe not...

    But what does happen is that sysops with more than 1 nodenumber
    (sometimes in fidonet, sometimes in different othernets), want to run
    more than 1 instance of binkd with seperate configurations. If they
    run those in different user accounts, you don't want to have those
    binkd instances look in the same location for their default
    configuration file.

    right...

    So although binkd is a server application and can be run as a daemon, APPDATA might be a good place for the default binkd configuration file location...

    thank you ;)

    )\/(ark

    ... By all means, let's not confuse ourselves by the facts.
    ---
    * Origin: (1:3634/12.73)
  • From Michiel van der Vlist@2:280/5555 to Binkd team on Wednesday, May 11, 2016 20:54:15
    Hello Binkd Team,

    I would like to see the following.

    On an incoming call binkd reports:

    - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499)

    What I would like to see is this:

    - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499) to 2001:7b8:2ff:3a9::2

    Where 2001:7b8:2ff:3a9::2 is one of my own IP addresses, the address that caller used to contact my binkd server.


    Reason:

    My binkd server is "multi homed". It can be reached via two different ways. Via
    my SixXs tunnel and via my he.net tunnel. In order to judge how effective this "multi homing" is, I would like to see via which channel an incoming call comes
    in.

    Tnx.

    Cheers, Michiel

    --- Fmail, Binkd, Golded
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Andrew Kolchoogin@2:5020/290.22 to Michiel van der Vlist on Thursday, May 12, 2016 11:00:24
    Hello Michiel.

    11 May 16 20:54, you wrote to Binkd team:

    My binkd server is "multi homed". It can be reached via two different ways.
    O.k.

    So, apply the following patch:

    ===
    -+- server.c.orig 2016-05-12 10:57:44.548610913 +0300
    +++ server.c 2016-05-12 10:54:42.000000000 +0300
    @@ -255,9 +255,12 @@
    }
    else
    {
    + struct sockaddr server_acceptaddr;
    + socklen_t server_acceptaddr_len;
    + char local_host[BINKD_FQDNLEN + 1];
    char host[BINKD_FQDNLEN + 1];
    char service[MAXSERVNAME + 1];
    - int aiErr;
    + int laErr, aiErr;

    add_socket(new_sockfd);
    /* Was the socket created after close_sockets loop in exitfunc()? */ @@ -269,16 +272,51 @@
    }
    rel_grow_handles (6);
    ext_rand=rand();
    + laErr = getsockname(new_sockfd, &server_acceptaddr, &server_acceptaddr_len);
    /* never resolve name in here, will be done during session */
    aiErr = getnameinfo((struct sockaddr *)&client_addr, client_addr_len,
    host, sizeof(host), service, sizeof(service),
    NI_NUMERICHOST | NI_NUMERICSERV);
    - if (aiErr == 0)
    - Log (3, "incoming from %s (%s)", host, service);
    + if (aiErr == 0)
    + {
    + if (laErr == -1)
    + {
    + Log(2, "Error in getsockname(): %s (%d)", strerror(errno), errno); + Log(3, "incoming from %s (%s)", host, service);
    + }
    + else
    + {
    + aiErr = getnameinfo(&server_acceptaddr, server_acceptaddr_len, local_host, sizeof(local_host),
    + NULL, 0, NI_NUMERICHOST | NI_NUMERICSERV);
    + if (aiErr == 0)
    + Log(3, "incoming from %s (%s) to %s", host, service, local_host);
    + else
    + {
    + Log(2, "Error in getnameinfo(): %s (%d)", gai_strerror(aiErr), aiErr);
    + Log(3, "incoming from %s (%s)", host, service);
    + }
    + }
    + }
    else
    {
    Log(2, "Error in getnameinfo(): %s (%d)", gai_strerror(aiErr), aiErr);
    - Log(3, "incoming from unknown");
    + if (laErr == -1)
    + {
    + Log(2, "Error in getsockname(): %s (%d)", strerror(errno), errno); + Log(3, "incoming from unknown");
    + }
    + else
    + {
    + aiErr = getnameinfo(&server_acceptaddr, server_acceptaddr_len, local_host, sizeof(local_host),
    + NULL, 0, NI_NUMERICHOST | NI_NUMERICSERV);
    + if (aiErr == 0)
    + Log(3, "incoming from unknown to %s", local_host);
    + else
    + {
    + Log(2, "Error in getnameinfo(): %s (%d)", gai_strerror(aiErr), aiErr);
    + Log(3, "incoming from unknown");
    + }
    + }
    }

    /* Creating a new process for the incoming connection */
    ===

    It's against binkd v1.1a-94.

    Andrew

    ... God made the people -- Colonel Colt made them equal
    --- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ
    * Origin: é«ßѼ¡áñµáΓδ⌐ ¿¡ΓÑα¡áΓ (2:5020/290.22)
  • From Andrew Kolchoogin@2:5020/290.22 to Michiel van der Vlist on Thursday, May 12, 2016 11:02:14
    Hello Michiel.

    12 May 16 11:00, I wrote to you:

    So, apply the following patch:

    ===
    -+- server.c.orig 2016-05-12 10:57:44.548610913 +0300
    As GoldED invalidates three dashes in a row because of tearline signature, "+" should be changed to "-" here.

    Andrew

    ... God made the people -- Colonel Colt made them equal
    --- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ
    * Origin: é«ßѼ¡áñµáΓδ⌐ ¿¡ΓÑα¡áΓ (2:5020/290.22)
  • From Michiel van der Vlist@2:280/5555 to Andrew Kolchoogin on Friday, May 13, 2016 00:57:53
    Hello Andrew,

    On Thursday May 12 2016 11:00, you wrote to me:

    So, apply the following patch:

    ===
    -+- server.c.orig 2016-05-12 10:57:44.548610913 +0300
    +++ server.c 2016-05-12 10:54:42.000000000 +0300
    @@ -255,9 +255,12 @@
    }
    else
    {
    + struct sockaddr server_acceptaddr;

    [..]

    It's against binkd v1.1a-94.

    Thanks.

    Unfortunately I am unable to do my own compile. So I hope it will be included in v1.1a-95.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/1 to Michiel van der Vlist on Friday, May 13, 2016 08:36:26

    13 May 16 00:57, you wrote to Andrew Kolchoogin:

    So, apply the following patch:
    It's against binkd v1.1a-94.

    Thanks.

    Unfortunately I am unable to do my own compile. So I hope it will be included in v1.1a-95.

    Meanwhile you may run two parallel servers with different "listen" and perhaps "log" lines in your configs.

    The easiest way is to play with "include". :)

    'Tommi

    ---
    * Origin: ====================================== (2:221/1)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Friday, May 13, 2016 13:39:30
    Hello Tommi,

    On Friday May 13 2016 08:36, you wrote to me:

    Meanwhile you may run two parallel servers with different "listen" and perhaps "log" lines in your configs.

    Hmmm. as an experiment I entered this in the config:

    listen [2001:7b8:2ff:3a9::2]
    listen 192.168.1.3
    listen [2001:470:1f15:1117:215:60ff:fe52:213d]

    Whereupon it crashed on the first incoming call.

    I coyuld not repeat the crash. But now I am a bit reluctant to experiment an further woth the listen command on a running system...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Andrew Kolchoogin@2:5020/290.22 to Michiel van der Vlist on Friday, May 13, 2016 15:47:06
    Hello Michiel.

    13 May 16 00:57, you wrote to me:

    So I hope it will be included in v1.1a-95.
    You have to spend some time kicking the ass of 463/68. :)

    BTW, my own BinkD works with this patch (or you will not see this message).

    Andrew

    ... God made the people -- Colonel Colt made them equal
    --- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ
    * Origin: é«ßѼ¡áñµáΓδ⌐ ¿¡ΓÑα¡áΓ (2:5020/290.22)
  • From Michiel van der Vlist@2:280/5555 to Andrew Kolchoogin on Friday, May 13, 2016 17:16:13
    Hello Andrew,

    On Friday May 13 2016 15:47, you wrote to me:

    So I hope it will be included in v1.1a-95.
    You have to spend some time kicking the ass of 463/68. :)

    Then I will do that. ;-)

    BTW, my own BinkD works with this patch (or you will not see this message).

    Of course it does. I trust you would not have published it until after testing it on your own system.

    --- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ

    Pen on parchment How old fashioned. And how nice. :)


    Cheers, Michiel

    --- GoldED+/W32-MINGW 1.1.5-b20110320
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Pavel Gulchouck@2:463/68 to Michiel van der Vlist on Monday, May 16, 2016 18:24:06
    Hi Michiel!

    13 May 16, Michiel van der Vlist ==> Andrew Kolchoogin:

    So I hope it will be included in v1.1a-95.

    You have to spend some time kicking the ass of 463/68. :)

    MvdV> Then I will do that. ;-)

    Got it. ;-)

    The easiest way to include a patch is create pull request on github.

    In this particular case I doubt that this patch is really useful. On most cases
    binkd is not multihomed, or it does not matter which local IP address was used,
    so it's redundant information in the log, obstructing to read it for most of sysops.

    If you need this info, you can get it by either run two separate binkd servers (with "include" common part in config) or get this information in the on_handshake() perl hook and put it to log.

    IMHO it's make sense to log local IP if multiple "listen" keywords specified in
    config. But you faced some problem in such configuration. I'll try to catch it,
    but not sure.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Andrew Kolchoogin@2:5020/290.22 to Pavel Gulchouck on Monday, May 16, 2016 22:17:07
    Hello Pavel.

    16 May 16 18:24, you wrote to Michiel van der Vlist:

    The easiest way to include a patch is create pull request on github.
    I dislike Github as any other public software development collaboration platforms.

    In this particular case I doubt that this patch is really useful. On
    most cases binkd is not multihomed,
    Yet. But as IPv6 deployment become wider, multihoming will 'an usual case'.

    If you need this info, you can get it by either run two separate binkd servers (with "include" common part in config) or get this information
    in the on_handshake() perl hook and put it to log.
    Or just apply a patch with 10 lines.

    Andrew

    ... God made the people -- Colonel Colt made them equal
    --- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ
    * Origin: é«ßѼ¡áñµáΓδ⌐ ¿¡ΓÑα¡áΓ (2:5020/290.22)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Monday, May 16, 2016 22:25:19
    Hello Pavel,

    On Monday May 16 2016 18:24, you wrote to me:

    You have to spend some time kicking the ass of 463/68. :)

    MvdV>> Then I will do that. ;-)

    Got it. ;-)

    Good. ;-)

    In this particular case I doubt that this patch is really useful. On
    most cases binkd is not multihomed, or it does not matter which local
    IP address was used, so it's redundant information in the log,
    obstructing to read it for most of sysops.

    True, it may not be usefull for most binkd users. But that goes for a lot of features. Plus that as Andrew also noted, mutihoming may become more common in the future.

    That it needlessly clutters the log for those that do not need it, can easely be remedied by making it an option.

    # Log the ip adress to which an incoming connection is addressed.
    # Useful in a multihomed setup or if binkp listens on more than one address.
    #
    # log-to-ip-on-incoming


    IMHO it's make sense to log local IP if multiple "listen" keywords specified in config. But you faced some problem in such configuration. I'll try to catch it, but not sure.

    It seems that the crashing has nothing to do with the multiple listen statements as such.

    Several versions I ago I reported that the windows version of binkd crashed when started withe the -C option when the config changes. I reported this bug was no longer manifest in version 1.1a-92 and onwards.

    It loooks like I was wrong. ;-( I tested it by touching an include file every five minutes. I let this run for a couple of weeks and it did not crash. But the test was wrong. It does indeed no longer crash when only the file date is changed, but I now found out that binkd still crashes occasianally when the /content/ of the config file or one of its includes changes. :-(

    I now think that when it crashed when I entered multiple listen statements, it did not crash on the listen statements as such, but on the mere fact that the content of the config file was changed wile binkd was running with the -C option.

    Testing continues...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Pavel Gulchouck@2:463/68 to Andrew Kolchoogin on Monday, May 16, 2016 23:28:00
    Hi Andrew!

    16 May 16, Andrew Kolchoogin ==> Pavel Gulchouck:

    In this particular case I doubt that this patch is really useful. On
    most cases binkd is not multihomed,
    Yet. But as IPv6 deployment become wider, multihoming will 'an usual
    case'.

    If you mean multistack (IPv4 + IPv6) than you can understand which IP protocol was used by remote IP address.
    Multihome is not usual case for binkd.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Michiel van der Vlist@2:280/5555 to Andrew Kolchoogin on Monday, May 16, 2016 22:46:44
    Hello Andrew,

    On Monday May 16 2016 22:17, you wrote to Pavel Gulchouck:

    In this particular case I doubt that this patch is really useful.
    On most cases binkd is not multihomed,

    Yet. But as IPv6 deployment become wider, multihoming will 'an usual case'.

    It may become more common. In fact there is one other sysop here in The Netherlands who has two connections and who is multihomed on IPv4 and who is thinking about how to implement multihoming for IPv6 for when his second ISP also starts supporting native IPv6.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Tuesday, May 17, 2016 00:58:59
    Hello Pavel,

    On Monday May 16 2016 23:28, you wrote to Andrew Kolchoogin:

    Yet. But as IPv6 deployment become wider, multihoming will 'an
    usual case'.

    If you mean multistack (IPv4 + IPv6) than you can understand which IP protocol was used by remote IP address.

    I don't think that is what he means.

    Multihome is not usual case for binkd.

    Not yet, but who knows what the future will bring.

    Anyway, even when one is single homed, it is normal to have mmultiple addresses
    on IPv6. Link local, ULA, SLAAC, static, DHCP6 and one or more PE addresses. Any of these addresses could be the target of an incoming binkp connection and it may be usefull to optionally log it for debug purposes.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Pavel Gulchouck@2:463/68 to Michiel van der Vlist on Tuesday, May 17, 2016 13:36:30
    Hi Michiel!

    17 May 16, Michiel van der Vlist ==> Pavel Gulchouck:

    Multihome is not usual case for binkd.

    MvdV> Not yet, but who knows what the future will bring.

    Multihome usually implemented on specialized hardware routers.
    Linux server with binkd and multiple network interfaces is exotic configuration.
    Two uplinks, hardware router, then PC with binkd is more common solution.

    MvdV> Anyway, even when one is single homed, it is normal to have mmultiple addresses on IPv6. Link local, ULA, SLAAC, static,
    MvdV> DHCP6 and one or more PE addresses. Any of these addresses could be the target of an incoming binkp connection and it
    MvdV> may be usefull to optionally log it for debug purposes.

    I do not object adding this information with debug log level.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: Ä»δΓ - øΓ« Γ«, τΓ« ¼δ »«½πτáѼ ó¼ÑßΓ« Γ«ú«, τΓ« σ«Γѽ¿ (2:463/68)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Thursday, May 19, 2016 00:44:30
    Hello Pavel,

    On Tuesday May 17 2016 13:36, you wrote to me:

    Multihome usually implemented on specialized hardware routers.
    Linux server with binkd and multiple network interfaces is exotic configuration. Two uplinks, hardware router, then PC with binkd is
    more common solution.

    We are an amateur network. What is exotic for the professional may be common for the amateur. Two network interfaces is what I have here. One is the LAN card in my PC, that gets its IPv6 address from the router wehere my he.net tunnel ends. The other is the virtual interface AICCU that terminates my SixXs tunnel.

    MvdV>> Anyway, even when one is single homed, it is normal to have
    MvdV>> mmultiple addresses on IPv6. Link local, ULA, SLAAC, static,
    MvdV>> DHCP6 and one or more PE addresses. Any of these addresses
    MvdV>> could be the target of an incoming binkp connection and it may
    MvdV>> be usefull to optionally log it for debug purposes.

    I do not object adding this information with debug log level.

    Good! Then please do so.


    But then... When you have added the code anyway, it would not be more than a few lines to also activate it as an option in all log levels as I proposed wouldn't it?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Binkd team on Sunday, November 05, 2023 19:54:26
    Hello Binkd Team,

    I would like to see the following.

    On an incoming call binkd reports:

    - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499)

    What I would like to see is this:

    - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499) to 2001:7b8:2ff:3a9::2

    Where 2001:7b8:2ff:3a9::2 is one of my own IP addresses, the address that caller used to contact my binkd server.


    Reason:

    My binkd server is "multi homed". It can be reached via two different ways. Via my SixXs tunnel and via my he.net tunnel. In order to judge how effective this "multi homing" is, I would like to see via which channel an incoming call comes in.

    Tnx.

    P.S.

    I wrote this in 2016. SixXs is gone and I no longer use a he.net tunnel. I had native IPv6 from the cable company. Since about two month however I also have FTTH. I kept my cable connection for the time being. In the foreseeable future I will make a choice but for now I am mulltihomed...


    Cheers, Michiel

    ---
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Oli@2:280/464.47 to Michiel van der Vlist on Monday, November 06, 2023 20:16:11
    Michiel wrote (2023-11-05):

    MvdV> Hello Binkd Team,

    MvdV> I would like to see the following.

    MvdV> On an incoming call binkd reports:

    MvdV> - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499)

    MvdV> What I would like to see is this:

    MvdV> - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2 (3499) to
    MvdV> 2001:7b8:2ff:3a9::2

    MvdV> Where 2001:7b8:2ff:3a9::2 is one of my own IP addresses, the address that
    MvdV> caller used to contact my binkd server.


    MvdV> Reason:

    MvdV> My binkd server is "multi homed". It can be reached via two different
    MvdV> ways. Via my SixXs tunnel and via my he.net tunnel. In order to judge how
    MvdV> effective this "multi homing" is, I would like to see via which channel
    MvdV> an incoming call comes in.

    A Perl hook might work. Something like:

    sub on_handshake
    {
    Log(3,"incoming to $our_ip $our_port");
    }


    or modify the "incoming" log message in the on_log() hook

    ---
    * Origin: No REPLY kludge - no reply (2:280/464.47)
  • From Tommi Koivula@2:221/360 to Oli on Tuesday, November 07, 2023 09:06:28
    Hi Oli.

    06 Nov 23 20:16, you wrote to Michiel van der Vlist:

    A Perl hook might work. Something like:

    sub on_handshake
    {
    Log(3,"incoming to $our_ip $our_port");
    }

    It shows outgoing too. Had to remove "incoming" :)

    07 Nov 09:05:20 [1361253] trying f1.n221.z2.binkp.net. [2a01:4f9:c011:1ec5:f1d0:2:221:1]...
    07 Nov 09:05:20 [1361253] connected
    + 07 Nov 09:05:20 [1361253] outgoing session with f1.n221.z2.binkp.net:24554 [2a01:4f9:c011:1ec5:f1d0:2:221:1]
    ? 07 Nov 09:05:20 [1361253] - our ip 2a01:4f9:c011:1ec5:f1d0:2:221:10 58727
    - 07 Nov 09:05:20 [1361253] OPT CRAM-MD5-95662b6e846d586131cf4c653088ecee
    + 07 Nov 09:05:20 [1361253] Remote requests MD mode
    - 07 Nov 09:05:20 [1361253] SYS RBB/2
    - 07 Nov 09:05:20 [1361253] ZYZ Tommi Koivula
    - 07 Nov 09:05:20 [1361253] LOC Lake Ylo, Finland
    - 07 Nov 09:05:20 [1361253] NDL IBN,CM
    - 07 Nov 09:05:20 [1361253] TIME Tue, 7 Nov 2023 09:05:19 +0200
    - 07 Nov 09:05:20 [1361253] VER binkd/1.1a-115/OS2 binkp/1.1

    'Tommi

    --- GoldED+/LNX 1.1.5-b20231028
    * Origin: nntps://news.fidonet.fi (2:221/360)
  • From Michiel van der Vlist@2:280/5555 to Oli on Tuesday, November 07, 2023 17:11:14
    Hello Oli,

    On Monday November 06 2023 20:16, you wrote to me:

    MvdV>> - 10 May 14:46:36 [756] incoming from 2001:16d8:ff00:306::2
    MvdV>> (3499) to 2001:7b8:2ff:3a9::2

    MvdV>> Where 2001:7b8:2ff:3a9::2 is one of my own IP addresses, the
    MvdV>> address that caller used to contact my binkd server.
    [..]
    A Perl hook might work. Something like:

    sub on_handshake
    {
    Log(3,"incoming to $our_ip $our_port");
    }

    Hmmm... I have neve used Perl, so I would have to delve ionto that to follow your suggestion. I am not all that eager to do that, I'd prefer a solution that makes it an integral part of binkd. I remember someone posting the code to do this some five years ago when I first brought it up, but I can't find it any more... :(

    * Origin: No REPLY kludge - no reply (2:280/464.47)

    Hé you stole that from me. ;-)


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Tuesday, November 07, 2023 17:15:47
    Hello Tommi,

    On Tuesday November 07 2023 09:06, you wrote to Oli:

    It shows outgoing too. Had to remove "incoming" :)

    That may be useful too. For someone who has no control over what IP is used on outgoing. Which brings uop something else. The limitations of the bindaddr keyword....

    See following messages.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)