search

hlsantos / wcSDK

Wildcat! Interactive Net Server SDK/API
5 stars 1 forks source link

test #1 Testing Issues #3

Closed hlsantos closed 4 years ago

hlsantos commented 4 years ago

Testing event notifications.

jkulwicki commented 4 years ago

Keep those updates coming, Hector.

Also. I've been messing with the library quite a little bit lately. I just wish there were built in methods for GetChar, Getstring, PrintLocalOnly. Sorry, just thinking out loud.

Thank you! -Jim

On Fri, May 1, 2020 at 3:24 PM hlsantos notifications@github.com wrote:

Testing event notifications.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hlsantos/WcSDK/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBKDMJ6GJZB5W322N2SG3RPMVYLANCNFSM4MXK7LWQ .

hlsantos commented 4 years ago

In what language? C#?

jkulwicki commented 4 years ago

Yes. c#.

On Sat, May 2, 2020, 10:52 AM hlsantos notifications@github.com wrote:

In what language? C#?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hlsantos/WcSDK/issues/3#issuecomment-622974064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBKDITFEPGUV7PWU7WHCTRPQ6S5ANCNFSM4MXK7LWQ .

jkulwicki commented 4 years ago

Hector, I mentioned a few methods that I'd like to see, and I only mention it, for speeding up development.

Here are some of the others that would be nice to see.

GotoXY, CursorUp, CursorDown CursorLeft cursorRight CursorSave CursorRestore DisplayFile Drawbox

As well as the ability to extract informtion out of the DOOR32.SYS file. WCAT Doesn't use DOOR32.SYS with a SDK written door, does it?

Thanks! -Jim

jkulwicki commented 4 years ago

Have you made any progress lately Hector?

hlsantos commented 4 years ago

I updated the wcdoor32 C# API and example with a ANSI door example #1. It has primitive dumb terminal. Next example #2 will be more advance. As a programmer, you should be able use the example and the API source code to get started.

jkulwicki commented 4 years ago

Okay, thank you.

WinserverSupport commented 4 years ago

Let me know of any help you need.

jkulwicki commented 4 years ago

What about for expanding WINS color codes?

On Sun, May 10, 2020 at 9:14 PM WinserverSupport notifications@github.com wrote:

Let me know of any help you need.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hlsantos/WcSDK/issues/3#issuecomment-626434711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBKDNPS5SB6R4AAHFUKPTRQ5NQZANCNFSM4MXK7LWQ .

WinserverSupport commented 4 years ago

What about for expanding WINS color codes?

Can you be more specific?

hlsantos commented 4 years ago

Please keep in mind that the current release of the C# wcDoor32 API, is not quite complete from a "OOPS" standpoint. I will provide two things:

1) WCT Macros to Local Console Emulation. This will allow wcSDK developers to create C# based CLI WcSDK utilities. Not just for doors

2) wcDoor32 that will allow the creation of wcDoor32 applications. This will use WCT macros which are expanded or you can direct ANSI escape sequences because the RTE (wcCore.DLL) will handle ANSI display.

Thats the goal. This would not just for wcDoor32.

jkulwicki commented 4 years ago

First of all, I downloaded the latest commit, and this one looks and works great! Thank you for creating this!!!

I have a few questions, how do I print to the screen extended ascii? I'd like to print box characters.

Also:

How do you detect if the user is in ANSI Emulation? Thanks again Hector! Sorry for being a pain. :)

-Jim

hlsantos commented 4 years ago

First, I am still working on this, I need to do some interop coding for the Win32/64 Console API because the C# console object is limited in this areas. In short you will soon have the functions and commands, and classes you need as soon as I am done. I will post what is stable at the various steps.

To detect if Ansi was Detected, you would use the the DoorSysValue(), example:

CWildcatDoor door = new CWildcatDoor() .... bool AnsiDetected = door.DoorSysValue("AnsiDetected") == "Y";

I will be be adding AnsiDetected to the CWildcatDoor class. So in the next update, you would reference the field

door.AnsiDetected

There is also already the door.ColorEnabled.

hlsantos commented 4 years ago

Here are some of the others that would be nice to see.

GotoXY, CursorUp, CursorDown CursorLeft cursorRight CursorSave CursorRestore DisplayFile Drawbox

Where did you get these functions names? I would like to keep with how wcBASIC or other console APIs named the functionalities. DisplayFile(), GotoXY() are set. The CursorXXXX() are not, nor DrawBox(). I can use these names. But I may change my mind, so that is why I ask, where did you get these particular function names? Are you using these names in other APIs?

As well as the ability to extract informtion out of the DOOR32.SYS file. WCAT Doesn't use DOOR32.SYS with a SDK written door, does it?

wcDoor32API class has the DoorSys32 logic. The CWildcatDoor class, the one you would use, inherits the wcDoor32API namespace.

jkulwicki commented 4 years ago

Hector, Because I am so familiar with RMLib these are just some of the functions that are contained in it. However an RMLib written door does not work with Wildcat. I do not know why. However, these are just some of the functions within RMLib.

Have a good day. -Jim

jkulwicki commented 4 years ago

Thank you for the 5/16/20 update. I appreciate it! I'm sure the community does as well.

hlsantos commented 4 years ago

You are welcome, Please feedback on all aspect. I should note the CursorSave() and CursorRestore() currently works with Telnet clients or any ANSI/VT100 client connection,.

jkulwicki commented 4 years ago

I've got a couple questions.

As I get deeper into the development I will definately give more feedback as well as more questions, I'm sure!

Thanks again, Hector! Great work! -Jim

hlsantos commented 4 years ago

WINS is virtual system, so "handles" are hidden from apps.

I am working on an API for WcDOOR32. That means specific to WINS only. However, using creative and knowledgeable OOPs programming, you can virtualize a new interface, There are so far two interfaces, CWildcatDoor and CWildcatLocal. The first one uses ANSI to write to wcDOOR32 which writes to the user's remote device. The 2nd one using the local .Net Console assembly. That is more meant for local apps. You can write an interface in WcDoor32API.cs that maybe writes to an handl, but like I said, handles are hidden not only from Doors, but also from Wildcat! itself. They come from the Hosting servers, i.e. wcTelnet server, wcModem Server. The handles ARE NOT passed to WCCORE.DLL which runs WCX programs. The WCX calls doors. So no one at the User side knows anthing about handles.

The IDEAL solution is for you to write an interface using the design in wcDoor32API.cs. But again, there is no handle to use from WILDCAT! But you can possibly get it from other systems. Just not Wildcat!

jkulwicki commented 4 years ago

Alright. That's what I thought. The reason why I even asked about it, is because as I said, I have a door written in RMLib about 45% done, and when you run the door, with no parameters, it returns the following:

USAGE:

DOORNAME.EXE

-C COMM TYPE (2=Telnet (Default), 3=RLogin, 4=WebSocket) -D PATH\FILENAME OF DROPFILE -L LOCAL MODE -H SOCKET HANDLE -N NODE NUMBER

Examples:

DOORNAME.EXE -L

Seeing as this door doesn't run in Wildcat by just passing the location of the drop file, like it does on Mystic & Synchronet, I thought maybe I could pass it the socket handle. I guess not, and would have to rewrite the door to work with Wildcat only. Not exactly ideal.

Thanks for the explanation. -Jim

On Fri, May 22, 2020 at 1:56 PM hlsantos notifications@github.com wrote:

WINS is virtual system, so "handles" are hidden from apps.

I am working on an API for WcDOOR32. That means specific to WINS only. However, using creative and knowledgeable OOPs programming, you can virtualize a new interface, There are so far two interfaces, CWildcatDoor and CWildcatLocal. The first one uses ANSI to write to wcDOOR32 which writes to the user's remote device. The 2nd one using the local .Net Console assembly. That is more meant for local apps. You can write an interface in WcDoor32API.cs that maybe writes to an handl, but like I said, handles are hidden not only from Doors, but also from Wildcat! itself. They come from the Hosting servers, i.e. wcTelnet server, wcModem Server. The handles ARE NOT passed to WCCORE.DLL which runs WCX programs. The WCX calls doors. So no one at the User side knows anthing about handles.

The IDEAL solution is for you to write an interface using the design in wcDoor32API.cs. But again, there is no handle to use from WILDCAT! But you can possibly get it from other systems. Just not Wildcat!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hlsantos/WcSDK/issues/3#issuecomment-632859197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBKDPCLH7XA5P6E6WHLTLRS3DEDANCNFSM4MXK7LWQ .

jkulwicki commented 4 years ago

Hector,

Is there anything in the SDK for getting a string, instead of just a character from the user or should I write a loop to get characters, until I get an enter or backspace?

Thanks. -Jim

On Fri, May 22, 2020 at 1:56 PM hlsantos notifications@github.com wrote:

WINS is virtual system, so "handles" are hidden from apps.

I am working on an API for WcDOOR32. That means specific to WINS only. However, using creative and knowledgeable OOPs programming, you can virtualize a new interface, There are so far two interfaces, CWildcatDoor and CWildcatLocal. The first one uses ANSI to write to wcDOOR32 which writes to the user's remote device. The 2nd one using the local .Net Console assembly. That is more meant for local apps. You can write an interface in WcDoor32API.cs that maybe writes to an handl, but like I said, handles are hidden not only from Doors, but also from Wildcat! itself. They come from the Hosting servers, i.e. wcTelnet server, wcModem Server. The handles ARE NOT passed to WCCORE.DLL which runs WCX programs. The WCX calls doors. So no one at the User side knows anthing about handles.

The IDEAL solution is for you to write an interface using the design in wcDoor32API.cs. But again, there is no handle to use from WILDCAT! But you can possibly get it from other systems. Just not Wildcat!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hlsantos/WcSDK/issues/3#issuecomment-632859197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESBKDPCLH7XA5P6E6WHLTLRS3DEDANCNFSM4MXK7LWQ .

jkulwicki commented 4 years ago

Are you able to post include in your examples, some sort of code for getting arrow keys? Thanks.

Thanks. -Jim

WinserverSupport commented 4 years ago

Most of the logic you need is there by recognizing the "Primitive Dumb Terminal." It is the primitive structure for a pure Interactive I/O communication model with the end user. All the examples show this dump terminal. This is a byte by byte recognition of keys. I suppose the kicker here is to understand the VT10x/ANSI Escape keys and IBM Extended Keys. I provided most of them, the arrows for example in the source code, see wcDoor32API.cs and see the examples,

Example #1 shows a basic dumb terminal and it watches for a slash or escape key to exit. See wcDoor321api.cs source to see the names of the keys.

Examples #2 and #3 shows how to use the Arrow Keys

4, I started to do menus and the GetString when I wondered if I should be duplicating what is already done in wcBASIC input library. I may just build a DLL library to be C# imported.

In short, this is not going to get done any time soon. I put wcSDK in GitHub, starting small, exclusive to a few to assist like you are, but also with your own coding and input.

Isn't the library you use for another system working in a similar way? Does it have a Input/Output Higher level library? Is so, most likely you can emulate the functionality.

All you need to learn or know about is the ANSI/VT100 and the IBM KeyBoard characters/bytes. You have a Primitive Dumb Terminal showing how to read bytes, act on them or just echoing it back.

Example #4 is the beginning of that work. But I may do it via a DLL import. Its all done in wcCore.dll already. I just need to expose it to the C# app. Once exposed, then all the coding logic in wcBASIC input library cmdLine.wcc/wch can be easily ported to C#.

Show me an example, a clip of how you read your input and spit out output.

jkulwicki commented 4 years ago

Hector,

Yes. I understand this SDK isn't going to be done any time soon, nor do I expect it to be. I appreciate your work on it greatly.

As you've requested:

In RMLib:

For a single key of input: char? TempCh = Door.ReadKey();

For the input of a line of text: strInput = Door.TextBox("", CharacterMask.All, '\0', 78, 78, 7).Trim();

And output as you've already incorporated Door.Write("Text with no carriage return unless appended");

And output WITH a carriage return: Door.WriteLn("Text with carriage return");

-Jim

WinserverSupport commented 4 years ago

WcDoor32 offers basic comm I/O it has the functions, or methods as its called in OOPs, you need plus more additional overloads which are methods with the same name, i.e. Write(), but provide it a string, a string with formatting, and an array of bytes. What it does not have is a higher level "Text-UI" framework for Text Windows, popups, etc. This is a more of a Dumb Terminal and dumb terminals may offer ANSI/VT100 support. I called them a little "smarter" dumb terminal. But to do popups, etc, we need another level that sits on top of wcDoor32.

The CWildcatDoor class in wcDoo32API.cs shows you what the Read/Write methods are. When there is no documentation and you need to write code, its a good idea to look at the language's prototype declarations for available functions. In C/C++ those are in .h header files. In wcBASIC, those are the .wch header files. In C# which is similar to C/C++ albeit not memory wise, it really doesn't have a header declaration idea with the exception of the Interface command. So look at WcDoor32API and you will see this:

public interface iWildcatConsoleIO
{
    string GetDeviceType();
    bool Initialize();
    bool PrepareCallBack();
    bool ShutDown();
    int Event(int msecs);
    bool Write(char ch);
    bool Write(byte[] data, int size);
    bool Writeln(byte[] data, int size);
    bool Write(string fmt, params object[] v);
    bool Writeln(string fmt, params object[] v);
    bool Writeln();
    int Read(ref byte[] data, int size = 1024);
    int Peek(ref byte[] data, int size = 1024);
    bool CharReady();
    uint ReadKey();
    void ClearScreen(string v = "2");
    int GotoXY(int x, int y);
    void EraseLine(string v = "");
    byte GetColor();
    byte Color(int fb);
    byte Color(int f, int b);
    void CursorUp(int amt = 1);
    void CursorDown(int amt = 1);
    void CursorLeft(int amt = 1);
    void CursorRight(int amt = 1);
    void CursorSave();
    void CursorRestore();
}

We have the read functions:

    bool CharReady();
    uint ReadKey();
    int Read(ref byte[] data, int size = 1024);

and now that should give you a ReadSting with masking. I am working on that project.

We have the rich set of write functions with overloads:

    bool Write(char ch);
    bool Write(byte[] data, int size);
    bool Writeln(byte[] data, int size);
    bool Write(string fmt, params object[] v);
    bool Writeln(string fmt, params object[] v);
    bool Writeln();

But we don't have the "Text-UI" with WcDoor32. You should write one!! :-)

WinserverSupport commented 4 years ago

What you can do with RMLIB is show them the WcSDK wcDOOR32 and I bet they can easily write a layer that supports the wcDoor32API library. Or they can directly with the Interop functions. I should probably separate them. This is the raw/basic wcDoor32 I/O functions, defined in it's wcDoor32.h c/c++ based header:

// // (c) Copyright 1998-2008 Santronics Software, Inc. All Rights Reserved. // // // File Name : wcdoor32.h // Subsystem : Wildcat! Door32 // Date : 03/07/2008 // Version : 452.5 // Author : HLS/SSI // // Revision History: // Build Date Author Comments // ----- -------- ------ ------------------------------------------- // 452.5 03/07/08 HLS - Added WCDOOR_EVENT_XXXXXX // - Added DoorEvent() // // 452.6 10/01/08 HLS - For consistency and to help reduce // long time conflict with door32.sys, // door32.h was renamed to wcdoor32.h // //***

ifndef __WCDOOR32_H

define __WCDOOR32_H

const DWORD WCDOOR_EVENT_BASE = 0; const DWORD WCDOOR_EVENT_FAILED = WCDOOR_EVENT_BASE + 0; const DWORD WCDOOR_EVENT_TIMEOUT = WCDOOR_EVENT_BASE + 1; const DWORD WCDOOR_EVENT_KEYBOARD = WCDOOR_EVENT_BASE + 2; const DWORD WCDOOR_EVENT_OFFLINE = WCDOOR_EVENT_BASE + 3;

ifdef __cplusplus

extern "C" {

endif

BOOL APIENTRY DoorInitialize(); BOOL APIENTRY DoorShutdown(); BOOL APIENTRY DoorWrite(const void data, DWORD size); DWORD APIENTRY DoorRead(void data, DWORD size); DWORD APIENTRY DoorReadPeek(void *data, DWORD size); DWORD APIENTRY DoorCharReady(); HANDLE APIENTRY DoorGetAvailableEventHandle(); HANDLE APIENTRY DoorGetOfflineEventHandle(); BOOL APIENTRY DoorHangUp(); DWORD APIENTRY DoorEvent(const DWORD timeout);

ifdef __cplusplus

} // extern "C"

endif

endif

The C# wcDoor32API.cs is a "Wrapper" that imports the above functions in the wcDoor32.dll. C# afford you to create higher level or layers of using the primitive functions that allow you to do more powerful things. That is why I said, I should probably separate the two, a pure interop import of the wcDoor32 functions, call that your "header" file and then the wcDoor32API could be better renamed to somethign like wcDoor32Helper. That is what we normally call them Helpers because they help you use the primitive layer.

Anyway, working on many things. I need to prioritize at this point. If you can get RMLIB to look at it, think they will see they can easily write a wcDoor32RMLIB.cs for you.

jkulwicki commented 4 years ago

Hi Hector. Sorry about these late replies. Unfortunately he told me he's no longer working on RMLib. The library is from 2006 I believe. I'm not concerned about that. I was just hoping to get RMLib working with WINS, and if I can't then so be it. I know you're a busy man, and have to prioritize projects, I noticed the commits on the SDK have slowed way down. I hope you don't lose interest.

Thanks. -Jim

hlsantos commented 4 years ago

OK, thanks. In all honesty, I need to move on. Software wise, it is all the same, but its A LOT. You are apparently use to the RMLIB API/Reference. No doubt, you can emulate the same functions in c# that use the Wildcat! functions. So you have a RMLIB class that describes the interface for the RMLIB library, just declare them, with empty shells. The one by one use the wcDOOR32 api function that match the functional of the RMLIB function. It is really not to hard to do, but takes time, testing, etc. But once you have this wcDoor32RMLIB.cs, you would be able to concentrate on writing apps instead of writing tools, libraries, etc.

hlsantos commented 4 years ago

I am going to close this issue. Thanks.