VOPS
in [Visual Objects]
|
From: Don Caton on 21 Nov 2005 08:08 "TSDing" <dingts(a)pc.jaring.my> wrote in message news:4381ba98_1(a)news.tm.net.my: > That is why I prefer to develop VO32. It will still run on a machine that > has .NET on it. Only problem > is Grafx is not doing much to improve the product. Ever since Grafx took > over, have you notice any > improvement on the Image Editor, Install Maker and Report Writter ? in fact > they have gone worse. Be realistic. Do you really want Grafx to spend time and money working on the image editor? Yes, it's awful and it always has been. But every company has limited resources, as you are well aware of. The install maker is based on ancient CA technology. Likewise, the report writer is also based on an ancient CA product called CA-Ret. Both were pretty bad to start out with, and I don't believe Grafx even has the code to either of these things. Better solutions are on the VO CD, so what's the problem? You could put full time developers on things like report writers and installers, but why reinvent the wheel when there are other people out there focusing their energies on those things? -- Don
From: Ginny Caughey on 21 Nov 2005 08:11 Don, > In general though, this whole thing really doesn't seem to be an issue. > It certainly doesn't seem to be impeding the migration from native to > managed applications. This is one of those things that I think people > tend to blow out of proportion. Agreed. We had this same issue with Valkyrie and Clipper apps. I remember giving a presentation at a Clipper conference on creating vertical market products and somebody asked me if I stayed awake at night worrying that my competitors would try to decompile my apps. I answered "No, because I know they're so arrogant they're staying awake at night worrying that I might try to decompile theirs". <g> It was sort of a joke, but after thinking about it, I realized that it was also true. In all the years I've been in this business, I've only had a couple of instances of piracy (as far as I know) and none of them involved decompiling my app - they just copied it. I have had since the Clipper days a small DLL written in C that my apps checks so the user can't take a text editor and just change the licensed name in my app, and I will continue to use that with the Vulcan.NET version too. That's how I found out about the piracy - a clerk called and wanted the name that printed on the bills to be changed. <g> Ginny
From: Don Caton on 21 Nov 2005 08:19 "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message news:3udungF103326U1(a)individual.net: > Yes that's right. When you create a .NET executable in debug mode, the pdb > file is automatically generated. When you release a product to a customer, > you'll build it in release mode, and you won't send them the pdb file. I > haven't checked, but the release mode might be less useful to reflect > against than the debug build anway. The only major difference in the metadata in release mode is that there is no symbolic names for local variables, so they have generic names like "V_1", "V_2", etc. The pdb file contains line number and sequence point information, which tell the debugger how to step from one place to the next, as well as some other symbolic info. It's also possible to embed the source code itself in a pdb file, although I'm not aware of any compilers that do that. But the vast majority of info for a decompiler comes from the IL code itself. It's somewhat easier to decompile IL code because there's far less IL instructions than there are native CPU opcodes. A decompiler writer can examine the output of C#, VB, etc. and see what code sequences those compilers emit and then look for those patterns when attempting to decompile IL code back to high level code. But it's still a guess. There's nothing inherent in IL or the metadata which allows the original source to be reconstructed, it's just easier because IL is a simpler thing to deal with compared to native opcodes. Given that there is often more than one way to express something, code obfuscators will often rearrange the IL code in such a way as to yield the same result, but which causes decompilers to decompile it to something much different than the original source code. -- Don
From: Ginny Caughey on 21 Nov 2005 09:19 Thanks for the details, Don. -- Ginny "Don Caton" <dcaton(a)shorelinesoftware.com> wrote in message news:nbqdnZhJ4K3-VBzenZ2dnUVZ_sudnZ2d(a)comcast.com... > "Ginny Caughey" <ginny.caughey.online(a)wasteworks.com> wrote in message > news:3udungF103326U1(a)individual.net: > >> Yes that's right. When you create a .NET executable in debug mode, the >> pdb >> file is automatically generated. When you release a product to a >> customer, >> you'll build it in release mode, and you won't send them the pdb file. I >> haven't checked, but the release mode might be less useful to reflect >> against than the debug build anway. > > The only major difference in the metadata in release mode is that there is > no symbolic names for local variables, so they have generic names like > "V_1", "V_2", etc. > > The pdb file contains line number and sequence point information, which > tell the debugger how to step from one place to the next, as well as some > other symbolic info. It's also possible to embed the source code itself > in a pdb file, although I'm not aware of any compilers that do that. > > But the vast majority of info for a decompiler comes from the IL code > itself. It's somewhat easier to decompile IL code because there's far > less IL instructions than there are native CPU opcodes. A decompiler > writer can examine the output of C#, VB, etc. and see what code sequences > those compilers emit and then look for those patterns when attempting to > decompile IL code back to high level code. But it's still a guess. > There's nothing inherent in IL or the metadata which allows the original > source to be reconstructed, it's just easier because IL is a simpler thing > to deal with compared to native opcodes. > > Given that there is often more than one way to express something, code > obfuscators will often rearrange the IL code in such a way as to yield the > same result, but which causes decompilers to decompile it to something > much different than the original source code. > > -- > Don >
From: TSDing on 21 Nov 2005 12:12
Yes, Grafx should improve not only those but on every expect of VO32. Thats what we expect when Grafx took over VO from CA. That is why most of use give Grafx our full support. It is Grafx that dissapoints us and lost our confidence. Solution on CD ? are you talking about the bunch of 3rd party demo version tools ? I know you are working hard on Vulcan.NET, you probably thinking that everyone will be happy to move from VO to Vulcan... but there are VO people who does not want Vulcan and does not believe it is possible to compile VO32 codes into a .NET. I dont know why so many people are so optimistic about it but for me I doubt a direct conversion of a complete VO32 gui application into Vulcan.NET is possible. Ding "Don Caton" <dcaton(a)shorelinesoftware.com> wrote in message news:xbudnWF6-qUnWxzenZ2dnUVZ_tadnZ2d(a)comcast.com... > Be realistic. Do you really want Grafx to spend time and money working on > the image editor? Yes, it's awful and it always has been. But every > company has limited resources, as you are well aware of. > > The install maker is based on ancient CA technology. Likewise, the report > writer is also based on an ancient CA product called CA-Ret. Both were > pretty bad to start out with, and I don't believe Grafx even has the code > to either of these things. > > Better solutions are on the VO CD, so what's the problem? You could put > full time developers on things like report writers and installers, but why > reinvent the wheel when there are other people out there focusing their > energies on those things? > > -- > Don > |