.NET Decompiler: "It was only a matter of time before decompiling of .NET Exe's and DLLs to MS Interlingua became a reality. Here are a couple of industry strength .NET decompilers which produces some incredibly accurate results.
Salamander is a .NET decompiler that converts executable files (.EXE or .DLL) from Intermediate Language (IL) binary format to high-level source codes, such as C#, managed C++, Visual Basic.NET, etc. For more than 8,000 classes that have been tested, Salamander always produces equivalent and recompilable codes that are remarkably close to the original source codes.
you can try it online here
Another very interesting decomplier is Ankarino, a very powerful command line tool which is provided as an open source utility, so you can get under the covers and see how it works.
give it a whirl here"
This is just a spot to keep miscellaneous links. It also shows you what a geek I am.
Wednesday, February 15, 2006
Canonical OPC .NET (DotNet) interoperability article on Google Groups (Dave Adair): "This is the source for my implementations at work. I believe the Dave in the discussion is Dave Adair.
http://groups.google.com/groups?hl=en&threadm=eWoEy3V8BHA.1380%40tkmsftngp03"
http://groups.google.com/groups?hl=en&threadm=eWoEy3V8BHA.1380%40tkmsftngp03"
Thursday, February 09, 2006
Slashdot | Debugging Asynchronous Applications?:
Some great suggestions from this article!
"Debugging Asynchronous Applications?
Posted by Cliff on Wednesday February 08, @08:20PM
from the mind-your-breakpoints dept.
Communications Programming
duncan bayne asks: 'I'm attempting to debug a complicated telephony application, written in C#, that's almost entirely event driven. This is the first time I've debugged a large asynchronous application that isn't a GUI, and I'm curious to know what advice the Slashdot crowd has to share - have you any recommended tools, best practices, or common pitfalls to avoid?'"
I'm not sure if you are 2.0 yet, but if you are, start by taking a look at VS2005. In the debug department, enhancements include better JIT debugging, stepping into XML/Web services from a client, and state-driven object inspection. Object Test Bench (OTB) is a simple object-level test utility. You create instances of your objects, invoke methods, and evaluate results... to shorten the task of coding, debugging and re-coding. I'm not sure about telephony specifically, but WSE/WS* SOAP layers can be hard to manuever through in a debugger, yet VS2005 does it quite nicely via WSDL.
One other suggestion... "event bus" apps like you describe are good candidates for capturing as much runtime data as possible, so make sure you adjust your build parameters and do as much of that as possible, especially in problem assemblies. Oh, and don't forget to build nUnits. Sounds like you're walking into some prewritten code, but the effort might be worthwhile.
Some great suggestions from this article!
"Debugging Asynchronous Applications?
Posted by Cliff on Wednesday February 08, @08:20PM
from the mind-your-breakpoints dept.
Communications Programming
duncan bayne asks: 'I'm attempting to debug a complicated telephony application, written in C#, that's almost entirely event driven. This is the first time I've debugged a large asynchronous application that isn't a GUI, and I'm curious to know what advice the Slashdot crowd has to share - have you any recommended tools, best practices, or common pitfalls to avoid?'"
I'm not sure if you are 2.0 yet, but if you are, start by taking a look at VS2005. In the debug department, enhancements include better JIT debugging, stepping into XML/Web services from a client, and state-driven object inspection. Object Test Bench (OTB) is a simple object-level test utility. You create instances of your objects, invoke methods, and evaluate results... to shorten the task of coding, debugging and re-coding. I'm not sure about telephony specifically, but WSE/WS* SOAP layers can be hard to manuever through in a debugger, yet VS2005 does it quite nicely via WSDL.
One other suggestion... "event bus" apps like you describe are good candidates for capturing as much runtime data as possible, so make sure you adjust your build parameters and do as much of that as possible, especially in problem assemblies. Oh, and don't forget to build nUnits. Sounds like you're walking into some prewritten code, but the effort might be worthwhile.
Tuesday, February 07, 2006
Programming Languages: Application and Interpretation | Lambda the Ultimate: "Programming Languages: Application and Interpretation
A new release of Shriram Krishnamurthi's programming languages book is available."
Scheme, Haskell, Prolog. He implements a lot of this crap in the book.
A new release of Shriram Krishnamurthi's programming languages book is available."
Scheme, Haskell, Prolog. He implements a lot of this crap in the book.
Friday, February 03, 2006
On this site you'll find some quick links to several sites about .NET, ASP.NET, upcoming technologies etc as well as links to my own articles and other projects I'm participating in.
I hope you enjoy your visit on my site! Also check out my technical blog which is updated far more regularly than this website :-).
Author: Bart De Smet, MVP on Visual C#
C Sharp - Wikipedia, the free encyclopedia: "C# (see section on naming, pronunciation) is an object-oriented programming language developed by Microsoft as part of their .NET initiative. Microsoft based C# on C++ and was influenced by some aspects of Java. C# has a procedural, object oriented syntax that combines aspects of several other programming languages, most notably C++, Java and Delphi. Since C#'s principal designer was the designer of Borland's Turbo Pascal, Turbo Pascal for Windows, and Delphi, concepts from those languages are apparent in C#. Other contributions can be traced on a programming language history chart. C# attempts to fit well for both rapid development, like Visual Basic or Delphi, and for complete full-featured desktop applications."
Thursday, February 02, 2006
Programming Language transformation? | Lambda the Ultimate: "Intentional Programming
There was Microsoft's Intentional Programming which does something along the line of what you want though less ambitious. SCID is a similar thing that was thought up earlier.
By Derek Elkins at Thu, 01/26/2006 - 18:59 | login or register to post comments
Re: SCID
SCID looks neat, thanks for the link! (Although, at least at first blush it reads like a hyper IDE vs. something which can transmogrify between horribly different languages.)
By raould at Thu, 01/26/2006 - 21:24 | login or register to post comments
Not automated but...
It can't really be automated at this point, but there are efforts being done for more language interoperability. .Net is one of the examples, and a lot of people are now reusing the JVM in order to be 'Java compatible'.
However for both of theses you need to target either an high level language (by generating Java or C# sources) or directly the VM bytecode (JVM or CLR). That's why I wrote NekoVM which defines an easy-to-target intermediate language and provide the VM and the libraries to run it.
It should greatly ease the language compiler implementation by providing a common runtime. And if you write a Neko -> Your language converter, you will be able to reverse the process, and translate other languages targeting Neko back into yours."
There was Microsoft's Intentional Programming which does something along the line of what you want though less ambitious. SCID is a similar thing that was thought up earlier.
By Derek Elkins at Thu, 01/26/2006 - 18:59 | login or register to post comments
Re: SCID
SCID looks neat, thanks for the link! (Although, at least at first blush it reads like a hyper IDE vs. something which can transmogrify between horribly different languages.)
By raould at Thu, 01/26/2006 - 21:24 | login or register to post comments
Not automated but...
It can't really be automated at this point, but there are efforts being done for more language interoperability. .Net is one of the examples, and a lot of people are now reusing the JVM in order to be 'Java compatible'.
However for both of theses you need to target either an high level language (by generating Java or C# sources) or directly the VM bytecode (JVM or CLR). That's why I wrote NekoVM which defines an easy-to-target intermediate language and provide the VM and the libraries to run it.
It should greatly ease the language compiler implementation by providing a common runtime. And if you write a Neko -> Your language converter, you will be able to reverse the process, and translate other languages targeting Neko back into yours."