Downloading files using TAPI instead of HyperT?

For all your TAPI and serial communications experts out there :-)

Before I spend time checking out TAPI and RAS, is it realistic to expect that I can do with TAPI and RAS32API.DLL all I can do with HyperTerminal manually, namely connect out to a modem, navigate through the usual BBS menus to select one or more files for download (through eg. *.exe), switch to ZModem, and hang up when I'm through?

Actually, I'd like to add support for RAS to a NSIS installer that currently only supports connections over the Net.

Thank you

Fred
Saturday, April 17, 2004

aaaiiieeee!!!!

What's the programming platform?

Serial communications and protocols - that way lies madness...

Philo

Philo
Saturday, April 17, 2004

Win32 :-) I know, but we just have quite a few customers who refuse to upgrade to the Net just yet, so it'd make our life much easier if I could just add that tiny part at the beginning on my installer.

Mmmm, wasn't there an ActiveX control made by DataComm that we bought a long time ago? Those of going serial comm with VB, what tools do you use?

Fred
Saturday, April 17, 2004

> is it realistic to expect that I can do with TAPI and RAS32API.DLL all I can do with HyperTerminal manually

No, I don't think so.

RAS is "dial-up networking": you dial from a RAS client to a RAS server; RAS establishes a SLIP or PPP connection between the two (i.e. Internet Protocol over modem instead of over LAN) ... you can then use the TCP/IP protocol ... so you might then be able to use FTP ... or HTTP ... or see the remote directory as a network drive (SMB or NFS) ... but not "navigate through the usual BBS menus".

TAPI lets you control telephony devices in various ways: establish a call ... play a voice file ... transfer a call ... I'm no TAPI expert but I think it's more for voice applications than data transfer ... it can be used with voice-modems, but most of it is more for controlling PBXs and agent call centers.

> Serial communications and protocols - that way lies madness...

I resemble that remark.

Christopher Wells
Saturday, April 17, 2004

OK, so I'll either play with TAPI if we stick to a BBS, or we set up a Windows host to act as RAS server, and use the RAS32 API. I can tell it's going to be fun :-) Thank you.

Fred
Saturday, April 17, 2004

if your users have tcip/ip et all installed, just not a live internet connection, then having them connect to your private network might be a reasonalbe way to handle the problem. no 'bbs' required, just whatever an ISP uses hooked up to a private data center.

disclaimer: i haven't done this sort of thing. though i did write most of a BBS in Applesoft Basic.

mb
Saturday, April 17, 2004

Check componentsource.com or vbxtras.com - if you can use an ActiveX control, do it. (I'm sure you're used to making sure it's not just a VB ActiveX...)

Look on the bright side - I spent four weeks dealing with a client that wanted to use dialup and kermit...

Philo

Philo
Saturday, April 17, 2004

Come to think of it, I have no idea how many customers have TCP/IP installed, but if they don't have the Net, it's pretty likely they only use NetBeui...

Kermit? Argh :-)

Fred
Saturday, April 17, 2004

TAPI cannot be used to download file. There are other things for transfering files. RAS, PPP, HyperTerm, old BBS protocols, UUEncoding, whatever. But TAPI is just a high level wrapper for telephony related stuff. When you press

1, TAPI gives you calls to read that sound from the proper time of hardware. (Other standards, like Linux Telephony, Solaris Telephony, and JTAPI do the same thing, in fact in some versions of JTAPI it's a wrapper over TAPI)

2. It lets telephony hardware designers (from the legacy day and today) expose their hardware features. Like voice mail box checking, gatewaying of long distance calls, menuing, special administrative features.

3. It lets you pipe pure IP telephony with legacy proprietary systems. Or IP to IP, etc.

In the telephony world generally they expect a person on that line, not a modem, at the very best it can listen for a few AT commands from the modem, but behind that it passes all negotiation for connections or PPP to a physical modem (internal or external), and once you hit that service you aren't talking TAPI routing or services but PPP services.

Li-fan Chen
Saturday, April 17, 2004

To do what you want the modern way, basically you have your clients (the people who has data to share), and your client's customers (who access these data, from here on forth referred to as customers).. to do what you want you should just ask your clients to serve PPP/RAS access points and serve these files using fairly standard IP-compliant services--as Philip Greenspun would say--get with the 90s for god's sake--IT'S ALREADY OVER. Once you get PPP going you can add additional transport services.

You can also do message-based or transport-level encryption and authentication/authorization for example--there are custom tools you can write to accomodate this but there are perfectly good commercialware or freeware like PSCP.exe that will do it.

Li-fan Chen
Saturday, April 17, 2004

So I can only use TAPI to connect and disconnect, possibly send some commands to the BBS server, but I have to find a way to download files with ZModem? Mmm...

Fred
Saturday, April 17, 2004

That would USD$700 thank you.

Li-fan Chen
Saturday, April 17, 2004

No, just forget about TAPI for now (trust us). Concentrate on RAS/PPP.

Li-fan Chen
Saturday, April 17, 2004

Thx for the info. If I don't find anything, I'll make the rounds to install TCP/IP on all the hosts that don't have it yet, and use RAS instead. Thank you all.

Fred
Saturday, April 17, 2004

To answer your question another way (because apparantly you may not know that much about telephony to even understand some of these explanations--no I am not insulting you--I just don't know how much you know about we are talking about here)

> Before I spend time checking out TAPI and RAS, is it realistic to expect that I can do with TAPI and RAS32API.DLL all I can do with HyperTerminal manually,

When you use HyperTerminal it's making a basic terminal connection. It sends and receives ASCII bytes, and the modem faithfully send them according to the rules of a basic terminal. You can raise the bar of the ASCII to cooler things for extended IBM graphics and ZModem at correct times with the help of a server (BBS software) that can be configured to cooperate with you. But basically it's sending ascii characters back and forth.

RAS and PPP requires your machine to have Internet Connection and Dial Up clients installed. Once you have this installed. Both of them makes the same ASCII connection. And using RAS/PPP the server and client raises the bar to do tcpip compliant service discovery transfers and data transfers. This is basically the new standard. Once RAS/PPP is setup (on the fly) it's up to you what you want to do..  of the things you talked about you just want to transfer files. FTP/SCP (provided by tools like PSCP.exe) all do this. If you want to automate this you have to get three things in order: 1. Set up a server, it serves the files. 2. Set up clients, they establish dial up and then ask for the files. 3. Automate the dial-up by making sure the server knows about your clients and has all the accounts and permissions set up, making sure the clients knows about the dial up and has a script that does basically three things: 3.1. dial up. 3.2. download the file, answering challenges if necessary. 3.3. hang up after file transfer completion.

This has little if not NOTHING to do with TAPI unless your company has a telephony system in place on those pesky dial-in laptops or at your data center and you guys use some custom TAPI application that you guys have programmers for dealing with this--AND for some reason TAPI is PREVENTING you from doing RAS/PPP. Otherwise really, do yourself a favor and forget about TAPI. It's not used for ftp by 99.9999999% of the world. (I don't even thing Internet Conneciton or Dial Up client in Win98/Windows 2000 uses TAPI at all. Someone correct me if I am wrong)

> Namely connect out to a modem, navigate through the usual BBS menus to select one or more files for download (through eg. *.exe), switch to ZModem, and hang up when I'm through?

Basically you just want to transfer files. Get RAS/PPP going. Get files shared (either Windows file share or something cool like SCP), once you have that going you are ducky.

Good luck.

J/K about the $700...

Li-fan Chen
Saturday, April 17, 2004

> So I can only use TAPI to connect and disconnect, possibly send some commands to the BBS server, but I have to find a way to download files with ZModem?

True, if you want to use the BBS and the BBS doesn't support any IP protocols.

I really don't think TAPI is what you want at all. For a data modem connecting to a BBS you (basically) do "ATDxxx" to dial, wait for the "CONNECT" string, ... programming in VB I'd expect to be able to find a (mature) 3rd-party COM component that can do this ... google for "ZMODEM".

Christopher Wells
Saturday, April 17, 2004

The problem for sticking with ZModem is that you are forced to do message-level encryption--hey, that's fine for some people, no one is going to chastise you for using GPG/PGP over ZModem, but it's clunky and your users will eventually beg you to get all sorts of other things working. Having proper PPP up going is going to save you a ton of wasted work later on (ZMODEM components and friends are component licensing cost and development licensing cost that you'll have to eat).

The only argument I can see against PPP can only be found in a test: Set up a test lab, send a 5K - 1 meg file. And ask the following question:

1. Which uses more bytes? This matters over CDPD modems, every byte is counted by the meter. And in fact you'll probably be begging for a programmer who knows UDP or SMS compression magic at this point.

2. Which one is more secure? Or more reliable? How well does PPP survive over cell phone? How about ZModem? Or UUencode over plain ASCII with hardware data correction (trying not to laugh here).

3. Are you deploying to 200 sales guys all over the States or to remote 200 health clinics in 3rd world nations? If they gotta save every dime PPP just might get bumped if the reason is good enough.

Li-fan Chen
Saturday, April 17, 2004

Ideally, I'd like to make this call and file transfer from NSIS, which AFAIK doesn't support COM. So it'd have to be a basic DLL such as http://www.wcscnet.com/CdrvLBro.htm.

Thanks everyone for your input :-)

Fred
Saturday, April 17, 2004

> I don't even thing Internet Conneciton or Dial Up client in Win98/Windows 2000 uses TAPI at all. Someone correct me if I am wrong

I think it does, at least at the kernel level, in Win2K: there's a TAPI driver between the RAS driver and the serial port driver: I guess because the RAS driver may also connect via other devices, such as X.25 or whatever.

> The problem for sticking with ZModem is that you are forced to do message-level encryption

If you need privacy, and if you think someone may be tapping your telephone line...


> Ideally, I'd like to make this call and file transfer from NSIS, which AFAIK doesn't support COM.

You said "Those of going serial comm with VB, what tools do you use?" If you find a COM component, you can write yourself a DLL that uses it. I'm guessing that you'll want a DLL with a single API function like "get file" that you can call from NSIS ... and a COM component with several API functions like "dial", "wait for connection", "send data", "receive data", "start zmodem transfer", ... and a DLL which implements the "get file" API by using the COM component to dial your BBS and talk with it.

Christopher Wells
Sunday, April 18, 2004

Yup, sorry about mentionning VB. It's because I was looking at a sample for RAS, hence the confusion with NSIS :-) The program will be written in NSIS, so I'm looking for either a command-line EXE or a non-COM DLL, since NSIS doesn't work with COM.

I went for a trip down memory lane, and found several solutions, ie. little EXE's and COM's from the early 90's. So far, it seems like I can either use the few one-in-all EXE's that can handle the modem part along with ZModem transfer, or use two, one to handle dialing out and hanging up, and a second program to handle the uploading/downloading in Zmodem, all this without bothering with TAPI or RAS.

Another solution I came accross is using a TCP/IP stack for DOS, so that I could use eg. FTP on hosts that currently only have NetBeui (which is likely since they don't use the Internet to begin with.)

Thanks again for the input :-)

Fred
Sunday, April 18, 2004

What's NSIS?

Philo

Philo
Sunday, April 18, 2004

A good, script-based tool to generated install programs. Originally written by the author of WinAmp.

http://nsis.sourceforge.net

Fred
Sunday, April 18, 2004

I know next to nothing about serial communications stuff, but I was able to use VB and HyperAccess (the full-featured upgrade from HyperTerminal) to do various things over a modem connection.  Most everything was pretty simple; as others have suggested HyperAccess interacts easily with VB via COM objects. 

The link for info on HyperAccess is here:
http://www.hilgraeve.com/hyperaccess/

Hilgraeve is actually the author of HyperTerminal that's included with Windows. 

Herbert Sitz
Sunday, April 18, 2004

Thank you Herbert. This is a good, enhanced version of HyperTerminal, and can be automated since it includes a COM object. Problem is, I can't access COM objects from an NSIS installer.

For those interested, at this point, I know of a few solutions:

- If connecting to a ZModem-capable BBS, I found a few ZModem modules, which usually don't do any more than this, ie. you must find an other program to handle the dialing/hanging-up part. TXZM is one of the very few that do both

- As for TCP/IP stacks for DOS, I read about Crynwr, Lsppp, WATTCP and Wat32

Fred
Sunday, April 18, 2004

Wow: you *have* been back to the 90s! I developed something with WATTCP and Crynwr once, back then, but we decided it wasn't worth shrink-wrapping:

- The PC needs to be running DOS, and have an Ethernet card.
- The customer need to know what make of Ethernet card they have, so that you install the right packet driver.
- The customer must have a LAN attached to the PC's Ethernet card (and, in your case, an internet connection from the LAN), and enough of an administrator than an IP address and Gateway address can be assigned to the box when it begins to run IP.
- The packet driver (which controls the Ethernet card hardware) is incompatible with running any other Ethernet driver on the PC (from example, a Netware driver).

If the customer *wants* to run IP on DOS then that may be the way to go ... but the above is not transparent to the customer (in the way that using their serial port and modem can be).

Christopher Wells
Monday, April 19, 2004

Actually, as far as I understand it, you don't need a packet driver for a PPP connection. That was only required if you wanted to do TCP/IP under DOS with Ethernet.

Looks like I found a way out:
1. NETDIAL.EXE to run a script
2. Any ZMODEM package to download files, such as Fwzmodem.exe, dsz, etc.

We're not getting any younger :-)

Fred
Monday, April 19, 2004

  Recent Topics

  Fog Creek Home