|
Hi All,
I am looking for code written in .NET that provides connection between application and telephone.
So that - the telephone will return a code according to input code that it get's from the user.
I'll be happy to get even a little help - if you know something that relate and can help me!!
Thanks.  
|
|
|
|
|
TAPI, TAPI, He's your man!
If TAPI can't do it, no one can!
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Wow, that was truly poetic 
modified 12-Sep-18 21:01pm.
|
|
|
|
|
as Jhon told you TAPI is the only way.
you can download c# wrappers here[^]
or you can use windows dll like this[^].
|
|
|
|
|
Thank you!
I would be happy to get more specipic help - about getting back answer from the telephone (and not dialinig to the talaphone from the computer).
Thanks again!
 ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
in the link u got, were the code here:
The code below is responsible for registering incoming calls so that they can be handled by our application. For that you need to select the line on which you want to receive calls and press the Register button.
Collapse Copy Code
try
{
registertoken[line]=tobj.RegisterCallNotifications(ia[line],
true,true,TapiConstants.TAPIMEDIATYPE_AUDIO,2);
MessageBox.Show("Registration token : "+
registertoken[line],
"Registration Succeed for line "+line);
}
catch(Exception ein)
{
MessageBox.Show("Failed to register on line "+line,"Registration for calls");
}The class given below is to be added depending upon your TAPI event handling requirements. This is specially designed according to the requirements of the application.
please read the article!!
|
|
|
|
|
I have no help
only DASH HAM!
|
|
|
|
|
In Visual C# if I force a recompile of unchanged source code the resulting executable are not the same. Can anyone define where they should be different and why or provide a tool that will indicate if two exe files came from the same source code?
Thanks,
Curt
|
|
|
|
|
Most likely they are different due to changes in the assembly metadata, like the file version and/or assembly version. How are you determining the files are not the same?
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
I used HexEdit to compare the files. In one case the difference was from:
{231F082C-31A4-4DF7-A34E-9B7383E240FD}
to:
{20EFE830-6E58-4A20-B725-F263FA47C142}
which looks like a regenerated version but in other cases the differences were just a few "random" bytes.
My customer expects to being able to confirm a certain set of files was used to create a executable by comparing the executable created at another time. Is there another way to confirm this?
|
|
|
|
|
As Luc said, it really isn't possible to do a binary comparison on a file and tell what changed about them. The best you can hope for is that you can tell the file didn't change.
The only way to recompile and have the resulting binary be the same is to ensure that absolutely nothing in the source code changes, including things like version stamps, etc.
It isn't clear what your customers real expectation is and why they want this ability. A good source control system and build process will ensure that you can recreate an executable from the same source each time.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
My customer has a medical device background (safety critical, high process) and I must PROVE the build process, especially when re-created on another machine, results in the same executable. Unfortunately, have good process isn't enough.
|
|
|
|
|
Hmmm...for the most part having a repeatable process has to be good enough. That is the basis for CMM certifications. Would computing a CRC or some other type of checksum on the files and comparing that checksum be enough?
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Considering there are plenty of situations where COM-exposed GUID are generated on every compile, and never the same between compiles, and between machines, you can't compare the two and come up with the exact same binary.
|
|
|
|
|
Hi,
IMO this is impossible:
- first, pretending to know at what locations EXE files could differ even when all the sources are the same is assuming a lot, e.g. is it documented the compiler must allocate objects in a specific order? is it documented the linker will always link things in the same order?
- second, assume you have the magic tool; I build once from some sources; I build again from the same sources (tool says: same source); now I replace one of the source files by a copy, modifying some comments, the name of a local variable, the order of two declaration statements, etc
and build again; the tool will tell you once more the sources were the same although they were not.
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:25 PM
|
|
|
|
|
It's fairly common, at least in the embedded development world, to compare "executables" in this manner, however the "executable" is a binary image that is loaded into a chip.
I didn't intend a file name comparison of the sources. I was hoping there was another way to insure two executables are from exactly the same source code/included libraries/etc.
|
|
|
|
|
Hi,
cwster wrote: It's fairly common, at least in the embedded development world, to compare "executables" in this manner,
I am aware of that, however the original question seemed very general; under controlled circumstances
(same PC, same tools, same settings, etc, the only possible difference is in one or more source files) one can do much better obviously.
On the other hand, COFF/IntelHex/whatever you use to download code would be much simpler than the
Windows Portable Executable file format.
But anyway, I can always come up with a different source that results in an "exe" that is so similar that no tool in the world will be able to tell whether the original source file was used or not.
(comments, local var names, declaration order, etc etc).
Suggestion: calculate checksums for each source file (use a separate tool that runs before building
the "exe", and somehow add a DATA section that gets to contain those checksums (this is not hard
when another little tool creates a new source file from all the checksums, possibly using
assembly code or linker commands).
Alternative: you could replace checksums by embedded version numbers, if you would trust those.
That would require e.g. an editor that always increments the version number automatically.
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:26 PM
|
|
|
|
|
You have to sign the assembly.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Signing the assembly will only show that it came from the same company, not the same source code. A CRC check might work, however.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
If you mean a CRC of the source code that wouldn't cover all the code linked in, etc.
If you mean a CRC of the exe, those I know to be different.
Did I miss your point?
|
|
|
|
|
Nope you didn't miss the point. I think I did. Disregard...
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
As others already said, it's impossible, because compiler and linker might behave differently each run.
What you could do is compile the executable with exactly the same compilation options (optimization level etc.) and tell from a diff of the IL code that nothing has changed in such a manner that it might influence the original flow of the program.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hi,
maybe you are asking the wrong question. If you want to relate an executable to other things such as source files, you could:
1.
either check in the executable itself, and provide dependencies as appropriate.
2.
or simply create a container that holds all requirements, analysis files, design files, sources, scripts, executables, data files, documentation, release notes, ... and everything that belongs to the same generation. I tend to use ZIP a lot for exactly that purpose: making snapshots in between releases,
and at release points. Disk space is cheap nowadays!
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:26 PM
|
|
|
|
|
Luc Pattyn wrote: Disk space is cheap nowadays!
Now you tell me! 
|
|
|
|
|
It's hard to do a binary comparison, as you'd have to understand the file format (PE/COFF/.NET Metadata/etc.) to know where where things like timestamps/GUIDs are stored.
However, since the files are C# .exe's, maybe you could disassemble them using ILDASM.exe and compare the resulting .IL files?
Try comparing the .IL of a few different compiles of the same source.
Hopefully the order of methods etc. won't change (same source, same compiler version, same ILDASM version => shouldn't change unless it depends on a timestamp or generated GUID).
And if you see changing version numbers or GUIDs in the IL output, they're much easier to filter out in the text version than in the binary version.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
