Register to post in forums, or Log in to your existing account
 

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion Goto page Previous  1, 2
Zugg Posted: Thu Apr 21, 2005 1:26 am
Bundling ZXL files with zAppLite.exe
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sun Apr 24, 2005 12:20 am   
 
So long as the application hits the scripting engine decrypted, there's little point to any form of protection... right... no matter how you protect the DLL or ZXL etc, when it hits the script engine plaintext you can copy that out and stick it in your own ZML and use it with the pro version?

Actual binary code in a DLL could be protected via normal means, provided that all your OnClick's etc were just 'call dllfunction()'...
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sun Apr 24, 2005 4:42 am   
 
Well, yes, you could get the scripts, a piece at a time. The scripts form only part of the application though. You don't get any of the control layout or property settings, or any of that. It's certainly possible to piece this all together, but tedious. And then you'd have to do it again when they release a new version. It's really no different then reverse engineering any program. There is never a foolproof way around any of this. The idea is to just make it enough of a pain that most people won't bother. And then if you are really worried about it, put important stuff in the DLL.
Reply with quote
Tarn
GURU


Joined: 10 Oct 2000
Posts: 867
Location: USA

PostPosted: Mon Apr 25, 2005 2:51 pm   
 
Zugg wrote:

What I would do is provide this "clean" DLL to 3rd party developers. They would then use zAppPro to convert their application (or part of it) to ZZL data that gets embedded into this special DLL file. Then, they either wrap the DLL with eLicense themselves (if they are an eLicense customer already), or they send me their DLL file and I wrap it for them.


Would that be source code, or a type definition for an ActiveX dll, or what? Is that the same DLL from the older thoughts that a developer would put key functionality in a DLL (application functionality, not cracking protection functionality).

Can you give an example of what would happen for a developer with a software package consisting of:
1. ZXL file for key code (protected)
2. ZML file for form layout, so the user can edit it
3. DLL file containing application-specific functionality, that should be protected

Zugg, other post wrote:

OK, I just finished a long phone discussion with the folks at eLicense and I've gotten permission to talk about more specifics. I personally think this is very exciting stuff, but I'll let you be the ultimate judge.


Sounds like a very easy way for a developer to get started. The price is pretty good considering that a new developer doesn't need to set up a merchant account or go through the hassles of finding/applying protection on his own.

How long do you think it will take to get all of that set up?

Zugg, other post wrote:

But yes, it is assumed that you don't wrap your application with eLicense until you are ready for a "real" release, and that you don't need to change the DLL very often.


I'm not sure if that's realistic. A small developer isn't going to have several guys in their "company" to test new features, so the beta versions will probably need to be protected too. A developer probably wants to be able to put out a new release (not constantly, but when a client is having a bad problem) the same or the next business day.

It's probably enough if you've got a reasonably automated system in place: developer emails an attachment to a special address at Zuggsoft, and after a quick look by you or Chiara to make sure that the developer is legit click a package/reply button in eMobius.

-Tarn
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Mon Apr 25, 2005 3:03 pm   
 
Tarn wrote:

It's probably enough if you've got a reasonably automated system in place: developer emails an attachment to a special address at Zuggsoft, and after a quick look by you or Chiara to make sure that the developer is legit click a package/reply button in eMobius.

-Tarn


Cool! I like that idea for eMobius! It's a great example of how a zApp developer/end-user could usefully expand eMobius.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Apr 25, 2005 4:43 pm   
 
Tarn, for your example, here is how it would work:

First, you would still need the source ZML file for your protected ZXL code. You load that ZML file into zAppPro and use the Embed option to embed this ZML code into your supplied DLL file. The ZML file would be encrypted and converted to the internal ZZL format, and then embedded into *your* DLL file. The other ZML file that contains your form layout would be distributed as normal. Or, you could "bind" this ZML file with the DLL so that when your application is run the first time, your ZML file would be automatically extraced from the DLL.

Then if you wanted the copy protection/elicense system, you'd send me the completed DLL and I would wrap it for you. Or, if eLicense decides that they will allow it, then you can wrap it yourself (still something we are negotiating). Then, you can use the Link option to link the DLL with zAppLite.exe to create MyApp.exe if you want.

When the user runs MyApp.exe, it first extracts the DLL file that is linked to it. Then, when it goes to run the DLL, it first extracts any files bound to it (your form ZML file in this example). Then zApp looks for the embedded ZZL data in the DLL and runs it as your application (after checking to make sure eLicense hasn't been tampered with if your DLL file was wrapped).

In the case where a developer doesn't have their own DLL file to embed the ZZL data into, I will provide one. This won't be source code...it will just be a regular DLL file with nothing else in it. Thus, developers who are not able to create DLL files on their own can use the supplied "raw" DLL file and perform the same steps above to deploy their application.

This this a bit more clear?
Reply with quote
Tarn
GURU


Joined: 10 Oct 2000
Posts: 867
Location: USA

PostPosted: Tue Apr 26, 2005 3:05 am   
 
Zugg wrote:

This this a bit more clear?


Perfectly. Sounds good.

When you're ready for some trial apps, I'd be happy to put some DLL's together from MS C++ and VB if you need some outside examples.

Just a few details questions:
1) Can eLicense protect OCX's?
2) Can eLicense protect multiple executables under the same end-user license purchase? (two DLL's, or a DLL and an OCX, maybe from different languages?)
3) When installing, do we register our DLL's ourselves or is that handled the first time the application gets run?

-Tarn
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Apr 26, 2005 3:14 am   
 
1) I think so. An OCX is just a DLL file in disguise, so I don't think eLicense cares. Haven't actually tried it though.

2) Yes. Any number of files can be protected with the same "ProductID". The first one of these files that tries to load will trigger the trial screen if the user isn't registered for that product id.

3) zApp will normally handle this. When it loads your DLL, it calls the "DllRegisterServer" routine in the DLL. This routine is the one that usually registers any COM objects or ActiveX controls. You can check to make sure your DLL has this routine and that it contains the proper code in different languages. I know that Delphi COM DLLs property implements this routine, and I think it's the Microsoft standard, but again, I haven't tested other languages.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Apr 26, 2005 3:26 am   
 
Actually, I mispoke a bit, so let me clarify:

zApp will automatically call the "DllRegisterServer" routine in the DLL that has the same name as the application you are running. So, for an application called MYAPP.EXE or MYAPP.ZML, zApp will try to load MYALL.DLL and will call the registration routine in that DLL.

If your application uses some other OCX file, zApp has no idea about this, so you are responsible for registering other external OCX files or other DLL files yourself.

Since I think OCX files are really just DLL files, I think you can probably rename your MYAPP.OCX file to MYAPP.DLL and then zApp will load it and register it for you, if that is what you are looking for. But we'll probably need to test this to make sure it really works. But I think OCX means: "this is an ActiveX DLL that supports all of the requires ActiveX routines", as opposed to a raw DLL file that doesn't have anything to do with ActiveX controls.
Reply with quote
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
© 2009 Zugg Software. Hosted on Wolfpaw.net