RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

03, 2016 04:37 To: profoxt...@leafe.com Subject: Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL) > Can you elaborate on that? Is that because of the binary storing in > VCX files? Would that also apply to SCX files too? > long vers

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

On 2016-12-03 04:36, Wollenhaupt, Christof wrote: Can you elaborate on that? Is that because of the binary storing in VCX files? Would that also apply to SCX files too? long version: http://foxpert.com/docs/security.en.htm *TL;DR:* SCX files are a bit more difficult, but not by much. The

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

> Can you elaborate on that? Is that because of the binary storing in VCX > files? Would that also apply to SCX files too? > long version: http://foxpert.com/docs/security.en.htm *TL;DR:* SCX files are a bit more difficult, but not by much. The approach is the same. SCX and VCX are opened in

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

I was keeping up. "Can you elaborate on that? Is that because of the binary storing in VCX files? Would that also apply to SCX files too? My business and data logic are all in PRGs so I'm just curious at this point (because it seems like I'm protected otherwise since you only listed VCX)."

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

On 2016-12-02 14:30, Stephen Russell wrote: vcx is a different name for a dbf file which is not secure at all. Steve, That's true, but you apparently missed the front part of this thread perhaps. We're talking about securing via 1 of the 2 3rd party tools I mentioned earlier in the

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

vcx is a different name for a dbf file which is not secure at all. On Fri, Dec 2, 2016 at 1:17 PM, wrote: > On 2016-12-02 13:54, Wollenhaupt, Christof wrote: > >> >>> Can you think of any other tool preferable to use for protecting your >>> deployed

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

On 2016-12-02 13:54, Wollenhaupt, Christof wrote: Can you think of any other tool preferable to use for protecting your deployed apps? Any comments on the two mentioned above? As long as you are aware that none of these tools will protect code that is stored in a VCX, they are both good

Re: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

> > Can you think of any other tool preferable to use for protecting your > deployed apps? > > Any comments on the two mentioned above? > As long as you are aware that none of these tools will protect code that is stored in a VCX, they are both good choices. -- Christof --- StripMime Report

Re: .prg Classes (Was: Re: Using a common class from another EXE/DLL)

On 2016-12-01 18:12, Gene Wirchenko wrote: At 15:04 2016-12-01, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: PERFECT...This is EXACTLY what I wanted to do. All I was missing was the SET PROCEDURE TO. (I use PRG classes.) So do I. The only time I do not is when I am setting

RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

: Using a common class from another EXE/DLL) On 2016-12-01 11:44, Carl Lindner wrote: > Mike, > > I have been using Armadillo aka Software Passport for years. I do not > know of any protection issues but my distribution to clients is > limited - in the couple dozen range. >

.prg Classes (Was: Re: Using a common class from another EXE/DLL)

At 15:04 2016-12-01, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: PERFECT...This is EXACTLY what I wanted to do. All I was missing was the SET PROCEDURE TO. (I use PRG classes.) So do I. The only time I do not is when I am setting printer orientation and have to use a .frx.

Re: Using a common class from another EXE/DLL

PERFECT...This is EXACTLY what I wanted to do. All I was missing was the SET PROCEDURE TO. (I use PRG classes.) Thanks, Fernando! On 2016-12-01 05:48, Fernando D. Bozzo wrote: If the library will be used only by another VFP apps, then there is another approach: Using an EXE as a library, so

RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

On 2016-12-01 11:44, Carl Lindner wrote: Mike, I have been using Armadillo aka Software Passport for years. I do not know of any protection issues but my distribution to clients is limited - in the couple dozen range. When I bought, it was purchased as 32 or 64 bit. That depended on the

RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

-Original Message- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of mbsoftwaresoluti...@mbsoftwaresolutions.com Sent: 12/01/2016 10:59 AM To: ProFox Subject: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL) On 2016-12-01 06:27, Ted Roche wrote: > Ag

RE: Using a common class from another EXE/DLL

Mike, You use a COM DLL without registering it. Rick Strahl has good explanation here. http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=890 Doug Hennig pointed to the article in his white paper I found through Google http://doughennig.com/papers/Pub/Deploying.pdf It also has a link

PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)

On 2016-12-01 06:27, Ted Roche wrote: Agree. Depends on the level of security you want/need. Compiling encrypted is enough to deter most. Nearly all Fox EXE / DLL can be decrypted, so if you *really* need it secure, look to a 3rd party solution, or move the secure parts off the client's machine

Re: Using a common class from another EXE/DLL

On Thu, Dec 1, 2016 at 3:24 AM, Alan Bourke wrote: > > Put it in a single .PRG in a folder somewhere, and just add it to the > project file for the projects you want to use it in, so that it gets > built into the EXE or APP? > > Don't see why it has to be a discrete DLL

Re: Using a common class from another EXE/DLL

If the library will be used only by another VFP apps, then there is another approach: Using an EXE as a library, so no need to register a DLL on the clients. *Approach 1:* Using VCX inside EXE You just compile an EXE with your classlib and then use externally on other VFP programs. Let's say

Re: Using a common class from another EXE/DLL

On 2016-12-01 05:26, Fernando D. Bozzo wrote: Yes, it have to be OLEPUBLIC, because OLEPUBLIC classes are the only that are published on the Windows Registry so other APPs (VFP and non-VFP) can instantiate them. ...but for these apps, I'm going to drop this 'blackbox' right into the App's

Re: Using a common class from another EXE/DLL

Yes, it have to be OLEPUBLIC, because OLEPUBLIC classes are the only that are published on the Windows Registry so other APPs (VFP and non-VFP) can instantiate them. 2016-12-01 3:19 GMT+01:00 : > On 2016-11-30 20:57,

Re: Using a common class from another EXE/DLL

On 2016-12-01 03:24, Alan Bourke wrote: Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP? Don't see why it has to be a discrete DLL or EXE. It needs to NOT be built into the EXE

Re: Using a common class from another EXE/DLL

Hi Mike, I want to be able to instantiate an object of this class and use it to > validate some things like login and license validation. > This is one of the things that sound easier than they are in VFP due to the program cache and VFP's project scope management. The cleanest approach would

Re: Using a common class from another EXE/DLL

On 01-Dec-2016 1:54 PM, Alan Bourke wrote: Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP? Don't see why it has to be a discrete DLL or EXE. +1

Re: Using a common class from another EXE/DLL

Put it in a single .PRG in a folder somewhere, and just add it to the project file for the projects you want to use it in, so that it gets built into the EXE or APP? Don't see why it has to be a discrete DLL or EXE. -- Alan Bourke alanpbourke (at) fastmail (dot) fm

RE: Using a common class from another EXE/DLL

On 2016-11-30 20:57, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: On 2016-11-30 17:52, Tracy Pearson wrote: Mike, An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations. If this is not the case, I would make it a

RE: Using a common class from another EXE/DLL

On 2016-11-30 17:52, Tracy Pearson wrote: Mike, An EXE suggests it will do something additionally to the functionality you are describing. Perhaps a UI or data validations. If this is not the case, I would make it a Multi-threaded COM DLL. Though that would mean you need to distribute the

RE: Using a common class from another EXE/DLL

mbsoftwaresoluti...@mbsoftwaresolutions.com wrote on 2016-11-30: > I want to create a "black box" of sorts with a class I've written. > There is no visible UI to it; it's just connection/validation stuff. I > want to use it across multiple projects. Do you suggest it be a DLL or > EXE? I