Julmar TSP++ based code to x64 platform

[karol.sotomski]

Hello,

Has anyone tried porting a custom TSP based on Julmar TSP++ to x64
platform? I already came across issues like casting pointers to DWORD
and _asm inlines.

Is there anything particularly problematic? Is it even possible (in
finite time;) )?

Best regards,
Karol

[Matthias Moetje [MVP]]

Karol,

I haven't done so yet, but I'm sure it's possible...

I don't remember any asm inlines, what are they
used for? (we are using only parts of the C++ code)

Best regards,

Matthias Moetje
-------------------------------------
TAPI WIKI: http://www.tapi.info
-------------------------------------
TERASENS GmbH
Augustenstra�e 24
80333 Munich, GERMANY
-------------------------------------
e-mail: moetje at terasens dot com
www: www.terasens.com
-------------------------------------

"karol.sotomski" <karol.s...@gmail.com> wrote in message
news:91b57f6e-bfed-438f...@y42g2000yqb.googlegroups.com...

[karol.sotomski]

Hello Matthias,

Thank you for your response:)

The asm is used as follows in spdll.cpp in SPLIB32:

///////////////////////////////////////////////////////////////////////////
// TSPI_lineBlindTransfer
//
// This function performs a blind or single-step transfer of the
// specified call to the specified destination address.
//
DLLEXPORT
LONG TSPIAPI TSPI_lineBlindTransfer (DRV_REQUESTID dwRequestId,
HDRVCALL hdCall, LPCWSTR lpszDestAddr, DWORD dwCountryCode)
{
_asm jmp tsplib_lineBlindTransfer;

}// TSPI_lineBlindTransfer

But I'm more concerned about casting pointers to DWORD all the time.
It seems like porting TSP based on TSP++ is a lot of work. Or maybe am
I missing something obvious?

Regards,
Karol

[Matthias Moetje [MVP]]

Karol,

> DLLEXPORT
> LONG TSPIAPI TSPI_lineBlindTransfer (DRV_REQUESTID dwRequestId,
> HDRVCALL hdCall, LPCWSTR lpszDestAddr, DWORD dwCountryCode)
> {
> _asm jmp tsplib_lineBlindTransfer;
>
> }// TSPI_lineBlindTransfer

I have really no idea why the chose to do this with asm...
Don't they supply a C++ alternative..?

> But I'm more concerned about casting pointers to DWORD all the time.
> It seems like porting TSP based on TSP++ is a lot of work. Or maybe am
> I missing something obvious?

No, I fear you have to change these things manually :-((

[karol.sotomski]

I wonder whether it would be faster to just take small parts of
Julmar's code and build a TSP from scratch considering my TSP is
rather simple and it's easier to find help working with TAPI/TSPI
rather than TSP++.
At first Julmar seemed great but now it's rather causing than solving
problems.
Anyhow, thank you very much for your help Matthias;)

Best regards,
Karol

[Matthias Moetje [MVP]]

Karol,

I totally agree with this. TSP++ is a lot of unneded overhead.
To make it extensible and flexible they chose to route certain
function through all instances of their objects.

On the other hand TSP++ contains a whole lot of useful comments,
implementation examples and details that you don't even get
from the MSDN documentation.
Furthermore it is very complete as it handles almost all TAPI features.
I'd say it is even better than all of the MS TSP's which I have seen
in source code..

What we have done is to use part of the TSP++ code and strip
out all unneded stuff and extension mechanisms, get rid of RTTI
and replaced MFC through ATL. All this was a real lot of work!
In the end I think it was worth it, because we only had to deal with
very few issues on the TAPI side because all these things are
already done in the correct way. On the other hand it also took
a lot of time to get familiar with the object structure as a lot of
functionality is ditributed accross several levels in the object
hierarchy.

Unfortunately there is no sample in between the very simple ATSP
sample from the SDK and TSP++, so you have to make your choice..

Best regards,

Matthias Moetje
-------------------------------------
TAPI WIKI: http://www.tapi.info
-------------------------------------
TERASENS GmbH
Augustenstra�e 24
80333 Munich, GERMANY
-------------------------------------
e-mail: moetje at terasens dot com
www: www.terasens.com
-------------------------------------

"karol.sotomski" <karol.s...@gmail.com> wrote in message

news:53edcd36-b037-4756...@33g2000vbe.googlegroups.com...

[Mathias Ellinger]

Hello,

yes it is possible and works on all 32 and 64 bits systems. Do not use
the internal jump layer for debugging from TSPI functions. Use
tsplayer.cpp as only interface or TSP interface not the other source
file (spdll.cpp)

Some function amd data structurs needs DWORD_PTR insteat DWORD.

like
typedef tsp_map<DWORD, CTSPIConnection*> TConnectionMap;
in spbase.h to

typedef tsp_map<DWORD_PTR, CTSPIConnection*> TConnectionMap;

regards
elli

[ckl]

"Mathias Ellinger" <me at ellisoft de> schrieb im Newsbeitrag
news:eE%23O8UOR...@TK2MSFTNGP06.phx.gbl...

> yes it is possible and works on all 32 and 64 bits systems. Do not use
> the internal jump layer for debugging from TSPI functions. Use
> tsplayer.cpp as only interface or TSP interface not the other source
> file (spdll.cpp)

Hallo Herr Ellinger,

I did this like you descried (by renaming tsplib_ functions in tsplayer.cpp
into TSPI_ ), e.g.

LONG TSPIAPI TSPI_providerEnumDevices (DWORD dwPermanentProviderID, LPDWORD
lpdwNumLines,
LPDWORD lpdwNumPhones, HPROVIDER hProvider, LINEEVENT
lpfnLineCreateProc,
PHONEEVENT lpfnPhoneCreateProc)
{

Compiles nd links fine, works with Debug builds, but crashes with Release
builds (when entering the respective TSPI_ function). Any idea what that
could be caused by?

Best Regards, Christoph

[ckl]

Hi,

I finally found the problem: Julmar has a strange library called
JTTSPTRC.DLL which crashes release builds when not using the spdll.cpp jmup
layer. Just don't load it and everything works fine (is of questionable
value anyway).

Regards, Christoph

"ckl" <c...@innovaphone.com> schrieb im Newsbeitrag
news:evaP70TY...@TK2MSFTNGP05.phx.gbl...