VOPS
in [Visual Objects]
|
From: Phil McGuinness on 21 Nov 2005 20:35 Ginny The person that wrote this was ex Microsoft developer and the amount of work in this is amazing. We found not only did it Obfuscate the code.. we could find no utilities on the web that could get the code back which was the original intention.. but it created one EXE distribution which was great as we support this code by remote access. None of the XP boxes at the other end have screens, keyboards or mouse. There is so much more it could do but we just did not have the time to play with everything. They have released the .NET2 version now. Phil McGuinness - Sherlock Software -- "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:3uev1mF10qko3U1(a)individual.net... > Hi Phil, > > I've heard good things about this product too. Thanks for the > recommendation. > > -- > Ginny
From: Geoff Schaller on 21 Nov 2005 21:18 Then that is useful to keep in mind. I still don't see much risk for large applications anyway. If even someone could make sense of the IL that came from what was probably 500,000 lines of commented code, its no trivial task. Even so, source code from a project that large is only part of the gig. It's the technical support and experience that tend to make the money so anyone trying to copy and setup in parallel has a bigger task than just providing the reverse engineered software. And if it costs as much to reverse engineer as to produce from new... Geoff "Don Caton" <dcaton(a)shorelinesoftware.com> wrote in message news:iMednSw_cPYQ7x_eRVn-gg(a)comcast.com: > "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message > news:43826d73$1(a)dnews.tpgi.com.au: > > > > Don, > > > > Ok, thank you for the correction. I thought I had seen that demonstrated > > but it must have been with debug on. It is probably then another good > > reason not to distribute debug versions. > > > I don't think there's any risk in distributing debug versions. The only > real difference between a .NET assembly compiled in debug mode is that > JIT compiler optimizations are turned off and line number information is > present. > > The line number information can be helpful in tracking down runtime > errors during development and beta testing. If you compile without > debug info, stack traces will only contain method names, no line > numbers, so it's harder to track down errors. > > -- > Don
From: Phil McGuinness on 21 Nov 2005 22:01 Geoff, In my market where they are say 5 companies constantly updating systems to add the same features to remain in the hunt... to be able to reverse engineer the .NET MSIL code would or could be a time saver. We have 5 development teams doing the same thing .. They try and buy each other out but it does not happen.. Phil McGuinness - Sherlock Software -- "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message news:43827fd5$1(a)dnews.tpgi.com.au... > Then that is useful to keep in mind. > > I still don't see much risk for large applications anyway. If even > someone could make sense of the IL that came from what was probably > 500,000 lines of commented code, its no trivial task. Even so, source > code from a project that large is only part of the gig. It's the > technical support and experience that tend to make the money so anyone > trying to copy and setup in parallel has a bigger task than just > providing the reverse engineered software. > > And if it costs as much to reverse engineer as to produce from new... >
From: Phil McGuinness on 21 Nov 2005 22:08 Geoff It is interesting to see how this FOX product works out. http://www.xenocode.com/Products/Fox/ Once you have the MSIL you can view the source in C# or VB.NET " Work in a language of your choice: Xenocode Fox allows code to be viewed in the C#, VB.NET, and IL assembly languages. Instantly translate between languages ? regardless of original source language. Phil McGuinness - Sherlock Software --
From: Geoff Schaller on 21 Nov 2005 22:07
Nick, I know this but it only happens once a day. Once I get the new front end installed it goes away. For now, if you went round all the PCs and deleted the local ...\Download folder, this message would go away. Geoff "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message news:43827fd5$1(a)dnews.tpgi.com.au: > Then that is useful to keep in mind. > > I still don't see much risk for large applications anyway. If even > someone could make sense of the IL that came from what was probably > 500,000 lines of commented code, its no trivial task. Even so, source > code from a project that large is only part of the gig. It's the > technical support and experience that tend to make the money so anyone > trying to copy and setup in parallel has a bigger task than just > providing the reverse engineered software. > > And if it costs as much to reverse engineer as to produce from new... > > Geoff > > "Don Caton" <dcaton(a)shorelinesoftware.com> wrote in message > news:iMednSw_cPYQ7x_eRVn-gg(a)comcast.com: > > > > "Geoff Schaller" <geoffxx(a)softxxwareobjectives.com.au> wrote in message > > news:43826d73$1(a)dnews.tpgi.com.au: > > > > > > > > Don, > > > > > > Ok, thank you for the correction. I thought I had seen that demonstrated > > > but it must have been with debug on. It is probably then another good > > > reason not to distribute debug versions. > > > > > > > I don't think there's any risk in distributing debug versions. The only > > real difference between a .NET assembly compiled in debug mode is that > > JIT compiler optimizations are turned off and line number information is > > present. > > > > The line number information can be helpful in tracking down runtime > > errors during development and beta testing. If you compile without > > debug info, stack traces will only contain method names, no line > > numbers, so it's harder to track down errors. > > > > -- > > Don |