I'm trying to leaen how to write doors. Under linux its simple, but realized under windows it relies on comm.

Still learning...

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (911:3589/0)

on 17 Jan 2023, mikey said...

I'm trying to leaen how to write doors. Under linux its simple, but realized under windows it relies on comm.

By far the easiest solution is to use a "door kit" which is essentially a library that handles all of that stuff (and usually more) for you. There are tons of them out there, but most of them deprecated due to what OSes and comm types they support. Some notable classic ones are OpenDoors for C/C++ (updated to support Win32 and DOOR32.SYS!) and DDPlus for Pascal. I think EasyDoor and DoorFrame might have been a couple of the popular ones for QuickBasic 4.5.

Demonic's own doorkit is XDoor. Versions prior to 3.00 are for Borland/Turbo Pascal and support comms via Fossil drivers under DOS, while 3.00+ adds in Win32 and OS/2 with DOOR32.SYS support for telnet by way of Virtual Pascal. I'm not sure if XDoor 3.xx properly supports Linux compilation or not, but that's something I mean to investigate (and perhaps fix) one of these days.

Xqtr is actually currently working on his own update of XDoor to add a bunch of new enhancements and features.

|08j |15A C K |08p |15H L A S H |08!

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: d i s t o r t i o n // d1st.org (911:1423/0)

By far the easiest solution is to use a "door kit" which is essentially a library that handles all of that stuff (and usually more) for you. There are tons of them out there, but most of them deprecated due to what OSes and comm types they support. Some notable classic ones are OpenDoors for C/C++ (updated to support Win32 and DOOR32.SYS!) and DDPlus for Pascal.
I think EasyDoor and DoorFrame might have been a couple of the popular ones for QuickBasic 4.5.

Demonic's own doorkit is XDoor. Versions prior to 3.00 are for Borland/Turbo Pascal and support comms via Fossil drivers under DOS,
while 3.00+ adds in Win32 and OS/2 with DOOR32.SYS support for telnet by way of Virtual Pascal. I'm not sure if XDoor 3.xx properly supports
Linux compilation or not, but that's something I mean to investigate
(and perhaps fix) one of these days.

Xqtr is actually currently working on his own update of XDoor to add a bunch of new enhancements and features.

Yep, I landed on the fact to use a door kit. I'm looking at one now, but man. Under linux it's damn easy. Just write to console and it works.

... A house is a place to keep your stuff while you go out and get more stuff

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Clutch BBS * telnet://bbs.clutchbbs.com (911:1519/1)

Twas Tuesday, January 17th when niter3 said...

Yep, I landed on the fact to use a door kit. I'm looking at one now, but man. Under linux it's damn easy. Just write to console and it works.

I'm still confused why people don't just do this across the board. Standard I/O (which is what that's doing) works on all OS's.



--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

I'm still confused why people don't just do this across the board. Standard I/O (which is what that's doing) works on all OS's.

Door kit appears to be needed under Windows.

I've landed on one, and I'm coding my door in this. Which should also work under Linux to... Less code work since the door kit takes care of a lot of procedures and function.

... I'd love to help you out. Which way did you come in?

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Clutch BBS * telnet://bbs.clutchbbs.com (911:1519/1)

On Wednesday, January 18th niter3 said...


On Wednesday, January 18th niter3 muttered...

Door kit appears to be needed under Windows.

Is this just a Mystic thing? Has anyone talked to g00r00? It *should* work just fine on Windows. stdio is stdio is stdio. It's one thing they all have in common. Windows implements it with Win32 vs POSIX, but that's easy to handle.

I have no doubt some of the door kits provide a nice API for "BBS stuff" or what not, but they could also just perform stdio in most of the cases. For non-compiled languages especially, you then have a door that can work on a lot of systems.



--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

Is this just a Mystic thing? Has anyone talked to g00r00? It *should*
work just fine on Windows. stdio is stdio is stdio. It's one thing they all have in common. Windows implements it with Win32 vs POSIX, but
that's easy to handle.

I can't comment. I'm new to creating doors. This is actually my first crack at one.

Standard Output from what I find, only works under linux.

I assume g00r00's reads these FTN messages. So hopefully he can comment on these.

Besides it being something perhaps Mystic can be fixed for, I want this door to work across all modern BBS packages that can run 32bit/64bit applications. I don't want it specific to Mystic.

... You can learn many things from children... like how much patience you have

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Clutch BBS * telnet://bbs.clutchbbs.com (911:1519/1)

Is this just a Mystic thing? Has anyone talked to g00r00? It *should*
work just fine on Windows. stdio is stdio is stdio. It's one thing they all have in common. Windows implements it with Win32 vs POSIX, but
that's easy to handle.

STDIO could be a good option for newer doors that don't want to support DOS, but it doesn't work the same as Linux. Every console application in Linux outputs to a terminal via VT and STDIO, so all applications can be redirected via STDIO. But console applications in DOS, Windows, and OS/2 use compiler RTL and those do not result in VT output to a terminal via STDIO. Those RTL call interrupts in DOS and OS-level API calls in Windows/OS2.

For example if someone makes this app in FreePascal:

TextColor(14);
WriteLn('My door in yellow');

It would not work properly when redirecting STDIO on anything other than Linux.

In terms of Mystic, it supports STDIO direction, named pipe redirection, direct socket handle redirection, and DOS FOSSIL via NTVDM. For various reasons, some work only on some operating systems. In Linux NTVDM isn't available. In Windows STDIO is disabled...

The reason I disabled STDIO in Windows is because people would try to redirect console applications like they did in Linux and it wouldn't work. It causes confusion when I have to explain why. And at least at the time there are zero ANSI-BBS STDIO doors available in Windows, so the feature served no purpose in Windows. I'd be open to adding it back though.

Some other things on this topic:

One reason to not push for this as the be all option for doors over using a toolkit is because it doesn't work for DOS doors. We can't go back and fix DOS BBS software so we're pretty much stuck dealing with FOSSIL if we want to hit the most people.

I have a PipeDoor toolkit for Pascal that works similarly where it can create DOS doors that output FOSSIL and it used named pipes on all other platforms. The reason for using pipes is because it can be emulated with disk-based pipes if needed on an obscure OS but it can also allow a separated local and remote user interface like DOS doors used to have.

Maybe I can rip out all the complexity and see how it'd work as using no local UI and only ANSI-based STDIO on non-DOS platforms and get a toolkit out there for people to use without having to think about it.

... Real Programmers balance their checkbooks in hex

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (911:1570/0)

Twas Thursday, January 19th when niter3 said...

Standard Output from what I find, only works under linux.
I assume g00r00's reads these FTN messages. So hopefully he can comment on these.
Besides it being something perhaps Mystic can be fixed for, I want this door to work across all modern BBS packages that can run 32bit/64bit applications. I don't want it specific to Mystic.

Standard I/O aka stdio aka stdin/stdout is really the lowest common denominator; Any OS can do it, so any modern BBS package should be able to as well. I'd think it should work with Mystic.

"DOOR32.SYS" wants to (generally) use socket sharing. This isn't terribly bad, but on Windows you basically have to do "deprecated" calls to do it -- that is, duplciate a handle and share it to another process/PID (I doubt they'll ever, at least in the near future, remove the functionality though). For some systems such as Node, the socket is maintained by the underlying event processing, so directly sharing isn't possible - I get around this by having a bridge (I call one I wrote "Bivrost!"). This can work for old doors written for COM ports if you emulate, but we're in 2023 now and we're all using Telnet, so /shrug.



--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

Standard I/O aka stdio aka stdin/stdout is really the lowest common denominator; Any OS can do it, so any modern BBS package should be able
to as well. I'd think it should work with Mystic.

Agreed outside of DOS either STDIO or named pipes should be the standard. I'm down to finish off my PipeDoor Pascal doorkit that takes this approach and release it open source, and work with you to establish the details on the rest if you're up for it. Then after that we'll get Rob and everyone else on board once we are good with it.

I forgot if I mentioned it earlier, Mystic already makes a pipedoor.ini file we can chat privately on what changes you'd want to it and I have a Pascal kit to go along with it that would work with STDIO. It would also produce DOS FOSSIL with the same code, so its a one stop shop for everything without confusing people like Mike with the behind the scene details.

So you'd have to add the drop file and me the STDIO into Windows, and then we'd get my kit out there.

"DOOR32.SYS" wants to (generally) use socket sharing. This isn't
terribly bad, but on Windows you basically have to do "deprecated" calls

Yeah I made DOOR32 in the 1990s, and obviously things have changed a lot since then. I had no vision of Linux or encrypted connections back then. Nor did I have any indicator that things like Node.js would exist someday to crank out scripted STDIO doors, etc. I've been saying for a long time that a new door standard needs to get out there...

I originally chose named pipes because then there is the option to use STDIO as a SysOp local console while using the named pipes for end user communication. I think its probably a more flexible solution than STDIO but I am open to either.

... A SQL query walks into a bar and sees two tables. Asks: 'Can I join you?'

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (911:1570/0)

On Thursday, January 19th g00r00 said...

For example if someone makes this app in FreePascal:

TextColor(14); WriteLn('My door in yellow');

It would not work properly when redirecting STDIO on anything other than

I'm not goign to quote much here because it's all researchable, but this isn't true. I literally do this with enigma all the time on Windows. When the parent launches the child, it needs to capture stdout (and technically stderr) and send input (from the client) to stdin.


On Thursday, January 19th g00r00 was heard saying...

One reason to not push for this as the be all option for doors over using a toolkit is because it doesn't work for DOS doors. We can't go back and fix DOS BBS software so we're pretty much stuck dealing with FOSSIL if we want to hit the most people.

I agree here, other than we're talking forward. If you're writing for retro tech, you get to stick with retro tech. That means socket sharing ala DOOR32 is also out. You're going to have to emulate e.g. a COM port.

Fun fact: I combine these often: COM port emulated via stdio: DOS see's "COM1" for example, I actually just use stdio to send data in/out.

On Thursday, January 19th g00r00 was heard saying...

Maybe I can rip out all the complexity and see how it'd work as using no local UI and only ANSI-based STDIO on non-DOS platforms and get a toolkit out there for people to use without having to think about it.

I think a lot of people would dig this as well.


g00r00 around Thursday, January 19th...

... Real Programmers balance their checkbooks in hex

lol



--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

For example if someone makes this app in FreePascal:

TextColor(14); WriteLn('My door in yellow');

It would not work properly when redirecting STDIO on anything other t

I'm not goign to quote much here because it's all researchable, but this isn't true. I literally do this with enigma all the time on Windows.
When the parent launches the child, it needs to capture stdout (and technically stderr) and send input (from the client) to stdin.

Its is true. Yes you can output ANSI to STDIO like you're saying, but that is not how console applications in Windows and OS/2 work unfortunately. Modern Windows didn't even translate ANSI until late Windows 10 ish, and that was only if you installed their terminal replacement. Lately Microsoft is moving to a more Unix-like approach thankfully.

One of the downsides of doing things in Pascal with an immature compiler is that Mystic is written in API, so I am very familiar with how each OS works at its lower level. A lot of that stuff is hidden from people using modern scripting, but I've had to use their APIs for over 20 years in Mystic.

Here's the API reference for console: https://learn.microsoft.com/en-us/windows/console/console-functions

And here is the source code to crt.pp in FreePascal so you can see these compiler RTLs use console APIs:
https://github.com/newpascal/freepascal/blob/master/packages/rtl-console/src/win/crt.pp

I know at some point Deuce was trying to write something that would capture the console buffer and compare it to a different buffer so it could translate it to ANSI STDIO, but I don't know if he ever finished anything. You can see further evidence of this when you look at SyncTerm and it has "Windows Console" as an option and "ANSI" as an option. Deuce had to specifically make an ANSI STDIO mode because Windows Console uses API and doesn't output terminal codes to STDIO.

... Radioactive cats have 18 half-lives

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (911:1570/0)

I think a lot of people would dig this as well.

Lots of details here. Tryinghg to wrap my head around this.

Sounds like g00r00's kit would make things easier having pipe codes and it would be more universal to hit all OS requirements, linux, windows, and dos behind the scene.

... One tequila, two tequila, three tequila, floor.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Clutch BBS * telnet://bbs.clutchbbs.com (911:1519/1)

g00r00 around Thursday, January 19th...

Agreed outside of DOS either STDIO or named pipes should be the standard.
I'm down to finish off my PipeDoor Pascal doorkit that takes this approach and release it open source, and work with you to establish the details on the rest if you're up for it. Then after that we'll get Rob and everyone else on board once we are good with it.

This and everything else you mention here sounds great, looking forward to it!


--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

Twas Thursday, January 19th when g00r00 said...

Its is true. Yes you can output ANSI to STDIO like you're saying, but that is not how console applications in Windows and OS/2 work unfortunately. Modern Windows didn't even translate ANSI until late Windows 10 ish, and that was only if you installed their terminal

Yeah for anything before 10, you need a shim, something like: https://github.com/adoxa/ansicon

Sounds like that's what Deuce was working on. I do keep forgetting MS only caught up (well, almost) with everyone else regarding terminals recently.

IIRC (though I can't think of the name) there are app(s) that you can proxy a app through to achieve this as well vs DLL injection like above.

Related: The people exposing their Win '95 and XP boxes to the internet to run 16bit apps vs using emulation have way bigger balls than me.





--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

Yeah for anything before 10, you need a shim, something like: https://github.com/adoxa/ansicon

Sounds like that's what Deuce was working on. I do keep forgetting MS
only caught up (well, almost) with everyone else regarding terminals recently.

Apparently Microsoft has developed their own shim now or is in the process? That sounds awesome but I wonder if it only works for current Windows 10 or 11 or if we could continue to use it on XP+. If it worked well and on XP+ it coud be game changing.

I haven't really kept up the past year or so with how they've been implementing these terminal changes and this article from a few months ago mentions it at the bottom in the "Future Planning and Psuedoconsole" section:

https://learn.microsoft.com/en-us/windows/console/classic-vs-vt

... One tequila, two tequila, three tequila, floor.

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (911:1570/0)

Agreed outside of DOS either STDIO or named pipes should be the stand
I'm down to finish off my PipeDoor Pascal doorkit that takes this approach and release it open source, and work with you to establish t details on the rest if you're up for it. Then after that we'll get R and everyone else on board once we are good with it.

This and everything else you mention here sounds great, looking forward
to it!

Awesome! I'll start working on it this weekend if I get time. First I'll get the STDIO working again in Windows but then I'll dig back into that doorkit and see what needs to be done. I'll ping you once I get organized and get your thoughts and feedback, etc.

... I know a good tagline when I steal one!

--- Mystic BBS v1.12 A49 2023/01/17 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (911:1570/0)

on 19 Jan 2023, g00r00 said...

Thanks for the educational discussion, guys. I've wondered about the possibility for using stdio that way with Windows myself, but assumed it simply wasn't possible and it sounds like it wasn't until (relatively) recently.

I forgot if I mentioned it earlier, Mystic already makes a pipedoor.ini file we can chat privately on what changes you'd want to it and I have a Pascal kit to go along with it that would work with STDIO. It would
also produce DOS FOSSIL with the same code, so its a one stop shop for everything without confusing people like Mike with the behind the scene details.

So you'd have to add the drop file and me the STDIO into Windows, and
then we'd get my kit out there.

Sounds like a... *glances at what echo this conversation is taking place in* future Demonic release in the making! ;) Seriously though, this does sounds like something quite a few of us could make some good use of. We've been in need of a good door kit with FOSSIL support for FPC for ages now, as you and I have talked about in the past.

|08j |15A C K |08p |15H L A S H |08!

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: d i s t o r t i o n // d1st.org (911:1423/0)

On Friday, January 20th g00r00 said...

Awesome! I'll start working on it this weekend if I get time. First I'll get the STDIO working again in Windows but then I'll dig back into that doorkit and see what needs to be done. I'll ping you once I get organized and get your thoughts and feedback, etc.

Sounds good!


--
|08 ■ |12NuSkooler |06// |12Xibalba |08- |07"|06The place of fear|07"
|08 ■ |03xibalba|08.|03l33t|08.|03codes |08(|0344510|08/|03telnet|08, |0344511|08/|03ssh|08)
|08 ■ |03ENiGMA 1/2 WHQ |08| |03Phenom |08| |0367 |08| |03iMPURE |08| |03ACiDic
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 16.16.0)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (911:1801/0)

Sounds like a... *glances at what echo this conversation is taking place in* future Demonic release in the making! ;) Seriously though, this does sounds like something quite a few of us could make some good use of.
We've been in need of a good door kit with FOSSIL support for FPC for
ages now, as you and I have talked about in the past.

While I always play with the shiny things, I'd love to write some doors in FPC... I'd be pumped to tear into a 'new' door kit, too.



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS>>>20ForBeers.com:1337 (911:1503/0)

Apparently Microsoft has developed their own shim now or is in the process? That sounds awesome but I wonder if it only works for current

So Microsoft is letting a few thousand workers. SO is Amazon.

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: d i s t o r t i o n // d1st.org (911:1423/0)