RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)
THAT was an excellent session at Southwest Fox this year. One of my all-time favorites. ;) Rick White Light Computing, Inc. www.whitelightcomputing.com -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: Saturday, December 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 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 the system data session when you execute them. Code injection allows you to copy those files out of the running application. Code in the OBJCODE is never encrypted. Clearly visible when you look at the help file for the COMPILE command and the ENCRYPT option. The report designer is always the easiest. If you let the user modify reports try this in your EXE: Open the report designer, right click to open the data environment, right click to add a file. Pick Other. In the file open dialog enter the name of a VCX or SCX file that is embedded in the EXE. The name must be in quotes. You will see the file being available in the report data environment. -- Christof --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/004c01d24e52$a9d9be30$fd8d3a90$@whitelightcomputing.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 approach is the same. SCX and VCX are opened in the system data session when you execute them. Code injection allows you to copy those files out of the running application. Code in the OBJCODE is never encrypted. Clearly visible when you look at the help file for the COMPILE command and the ENCRYPT option. The report designer is always the easiest. If you let the user modify reports try this in your EXE: Open the report designer, right click to open the data environment, right click to add a file. Pick Other. In the file open dialog enter the name of a VCX or SCX file that is embedded in the EXE. The name must be in quotes. You will see the file being available in the report data environment. WOW! Glad I use PRG classes! ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/f45252905b761deb6ed19a8d73fd2...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 the system data session when you execute them. Code injection allows you to copy those files out of the running application. Code in the OBJCODE is never encrypted. Clearly visible when you look at the help file for the COMPILE command and the ENCRYPT option. The report designer is always the easiest. If you let the user modify reports try this in your EXE: Open the report designer, right click to open the data environment, right click to add a file. Pick Other. In the file open dialog enter the name of a VCX or SCX file that is embedded in the EXE. The name must be in quotes. You will see the file being available in the report data environment. -- Christof --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAL4QJhg=s2k7f53nyfh8uso4foskje3upatbvybdbiqrr_9...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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)." Combining the dbf-like container in your dll or exe is easily consumable unless the file itself, dll or exe, is secured. Or it is just as safe as a prg in the same dll-exe. On Fri, Dec 2, 2016 at 1:36 PM, wrote: > 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 thread. Try to keep up. > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmy+uuvbhfupaoxf8ybbbgwdt7rvpd-ozt8mwaceq04j...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 thread. Try to keep up. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/355c17e997b4a2b969c3494f004ae...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 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. >> > > > Hi Christof, > > 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). > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAJidMYK+UWF_DHu-JXb4D43LTP4=c1_lbhjdztko-gn-+bf...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 choices. Hi Christof, 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). ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/c1f44a88d66ac4a4ee54ebe400b62...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cal4qjhg_ato99jhjzwqvbk8rb_8s-gx14jouirxmra8+x-9...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 printer orientation and have to use a .frx. Do we have any other .prg class users? Should we be trading notes? (GUI classes get most of the coverage, and some solutions do not work for .prg classes.) My PRG classes are for my business and data objects; I use SCX and VCX for visual things like forms and controls. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/8914067abb64bf64744420cb8a290...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)
Mike, Long time... So, if things have not changed, you get the 64 bit and encrypt in your environment. The client environment does not matter. Years ago I researched encryption very hard and went with Software Passport. I had some quirky problems with Win 7-32 and the developer helped resolve them. It hurts to see a good product fail. Carl -Original Message- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of mbsoftwaresoluti...@mbsoftwaresolutions.com Sent: Thursday, December 01, 2016 6:00 PM To: ProFox Email List Subject: 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 > source machine, not the target. > > Carl Thanks, Carl. My machines are 64-bit, but I'm sure some clients out there still have 32-bit. [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/!&!AAAYAG5bUi4Gq6hEgJNCRZwAd1milwAAEPVTasDJjFlBqU/BP9Ls3qMBAA==@bdos.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
.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. Do we have any other .prg class users? Should we be trading notes? (GUI classes get most of the coverage, and some solutions do not work for .prg classes.) [snip] Sincerely, Gene Wirchenko ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/47ce53807ed38b6a9defacd142a6dfc9@mtlp86 ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 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 that youur library is called "mytestlib.vcx" and the class
you
want to instantiate is called "operations", which have methods for
mathematical operations:
*- In you other VFP Apps:
oOps = NEWOBJECT("operations", "mytestlib.vcx", "test_obj.exe")
? oOps.get_sum(1,2)
*Approach 2:* Using your library not as VCX, but as PRG and doing it
the
main program of the EXE
Let's say you have this program as the main program of the
"test_obj.pjx"
project:
* main_test_lib.prg
DEFINE CLASS MyClassLib as Custom
FUNCTION Get_Sum(value1, value2)
RETURN value1 + value2
ENDFUNC
ENDDEFINE
Then, when you want to instantiate this class, you can do it this way:
SET PROCEDURE TO test_obj.exe
oOps = CREATEOBJECT("myclasslib")
? oOps.get_sum(1,2)
There are other approaches, but I think that any of these can be useful
to
you.
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/4e2c80e64b5fa62910779b8533d96...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 source machine, not the target. Carl Thanks, Carl. My machines are 64-bit, but I'm sure some clients out there still have 32-bit. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/b6dab7e3b81d4dad5a9497c15016a...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
RE: PROTECTING YOUR DISTRIBUTED CODE (was Re: Using a common class from another EXE/DLL)
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 source machine, not the target. Carl -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: > 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 and > require them to contact a web resource you control so they can't > access it. I recall somebody mentioning Armadillo to protect your EXEs in the past (from reverse engineering): http://www.freedownloadscenter.com/Programming/Registration_Tools/The_Armadi llo_Software_Protection_System.html ReFox also offers protection: http://www.refox.net/-overview.html Can you think of any other tool preferable to use for protecting your deployed apps? Any comments on the two mentioned above? tia, --Mike [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/!&!AAAYAAZ6acx/WBlNqEIsKHz6tc0ClgAAEPO1IYA9AOdAqlP36gi0xdUBAA==@bdos.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 to Craig Boyd's site with similar information. Tracy Pearson PowerChurch Software ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/000f01d24bee$1a551950$4eff4bf0$@powerchurch.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 and require them to contact a web resource you control so they can't access it. I recall somebody mentioning Armadillo to protect your EXEs in the past (from reverse engineering): http://www.freedownloadscenter.com/Programming/Registration_Tools/The_Armadillo_Software_Protection_System.html ReFox also offers protection: http://www.refox.net/-overview.html Can you think of any other tool preferable to use for protecting your deployed apps? Any comments on the two mentioned above? tia, --Mike ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/ed83e93973899f647c9725b8deb6b...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 or EXE. > 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 and require them to contact a web resource you control so they can't access it. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4v3mzGd4MprzNZJNY=eRUiCQfcR2k3DoUvfC3B=okt...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 that youur library is called "mytestlib.vcx" and the class you
want to instantiate is called "operations", which have methods for
mathematical operations:
*- In you other VFP Apps:
oOps = NEWOBJECT("operations", "mytestlib.vcx", "test_obj.exe")
? oOps.get_sum(1,2)
*Approach 2:* Using your library not as VCX, but as PRG and doing it the
main program of the EXE
Let's say you have this program as the main program of the "test_obj.pjx"
project:
* main_test_lib.prg
DEFINE CLASS MyClassLib as Custom
FUNCTION Get_Sum(value1, value2)
RETURN value1 + value2
ENDFUNC
ENDDEFINE
Then, when you want to instantiate this class, you can do it this way:
SET PROCEDURE TO test_obj.exe
oOps = CREATEOBJECT("myclasslib")
? oOps.get_sum(1,2)
There are other approaches, but I think that any of these can be useful to
you.
2016-12-01 11:07 GMT+01:00 Wollenhaupt, Christof <
christof.wollenha...@foxpert.com>:
> 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 be to have a main program in that EXE that instantiates the object:
>
> LParameter tcAction, roRef
>
> Do case
> Case Upper(m.tcAction) == "CREATE"
> roRef = NewObject("Test", "test.prg")
> EndCase
>
> Then build the EXE and call it like this:
>
> Local loTest
> Do Test.EXE with "CREATE", loTest
> ? loTest.Hello ()
>
> Obviously you would need to create your own set of actions and also handle
> parameters if your class needs those.
>
> A caveat, your other applications should not include a file or a class that
> has the same name as the ones in your EXE, or VFP can sometimes confuse
> both and crash.
>
>
> --- StripMime Report -- processed MIME parts ---
> multipart/alternative
> text/plain (text body -- kept)
> text/html
> ---
>
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/cagq_junyvewukjlhy6m5juzyqj54x1-46k2kxqmamnykwac...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 folder so I won't need to worry about other applications elsewhere needing to grab it from the registry location. Well, I guess I could design it so that I just use one instance via the OLEPUBLIC (registry) route. I should look at using encrypted meta-data I suppose to rethink my approach. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/0b663878e26682aa9c7e752388e7a...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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, 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 Multi-threaded COM DLL. Though
>>> that would mean you need to distribute the VFP9T.DLL.
>>>
>>> There is the Single-threaded COM DLL as another option. I believe it does
>>> not require the VFP9T.DLL.
>>>
>>
>>
>> Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL
>> approach but for some reason it didn't work. It's not an OLEPUBLIC
>> class (at least not yet); it's just a Separator class (to be
>> lightweight, although in today's world, nobody would notice the
>> difference between a Separator and Session or Custom class).
>>
>> I was trying to invoke it this way:
>>
>> IF tlEntering THEN
>> loLicense =
>> NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
>> tlEntering, .F., pcPrintID, this.oUser.cUserID,
>> this.oClient.cClientName, STRTRAN(_screen.cAppName,'\','\\'))
>> this.iLicenseKey = loLicense.iLicenseKey
>> IF this.iLicenseKey < 1 THEN && problem
>> llOK = .F.
>> loLicense.ShowMessage()
>> ELSE
>> llOK = .T.
>> ENDIF
>> ELSE && exiting software; release license
>> loLicense =
>> NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
>> tlEntering, this.iLicenseKey, pcPrintID)
>> IF loLicense.lProblem THEN
>> llOK = .F.
>> loLicense.ShowMessage()
>> ELSE
>> llOK = .T.
>> ENDIF
>> ENDIF
>>
>> It doesn't instantiate.
>>
>
>
> Does it have to be an OLEPUBLIC class? I'm not doing that currently:
> DEFINE CLASS MBSS_Licensor AS Session
>
> I'm trying to avoid the registry; I just want to plunk the DLL into the
> App's folder and have it reference it from there.
>
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/cagq_jum4c8ttxgsd9ow87sg8d+qonjv-n-gubs86uo04lat...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 in case I want to change something and don't want to rebuild the main EXE. I chose the "discrete" external route because I don't want the code "visible" to anyone. ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/76ac7f1ec359efda5fd9bfc57ad5a...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 be to have a main program in that EXE that instantiates the object:
LParameter tcAction, roRef
Do case
Case Upper(m.tcAction) == "CREATE"
roRef = NewObject("Test", "test.prg")
EndCase
Then build the EXE and call it like this:
Local loTest
Do Test.EXE with "CREATE", loTest
? loTest.Hello ()
Obviously you would need to create your own set of actions and also handle
parameters if your class needs those.
A caveat, your other applications should not include a file or a class that
has the same name as the ones in your EXE, or VFP can sometimes confuse
both and crash.
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/CAL4QJhgz8OH9Hbg_MikqRD8Ekq2U9PN7+Lt4CVY8BWHuSL1N=w...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/1ee889c0-ad1f-9a3b-f9d2-baae19a40...@hawthorncottage.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/1480580686.375473.804744625.0e6b9...@webmail.messagingengine.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
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 Multi-threaded COM DLL.
Though
that would mean you need to distribute the VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it
does
not require the VFP9T.DLL.
Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL
approach but for some reason it didn't work. It's not an OLEPUBLIC
class (at least not yet); it's just a Separator class (to be
lightweight, although in today's world, nobody would notice the
difference between a Separator and Session or Custom class).
I was trying to invoke it this way:
IF tlEntering THEN
loLicense =
NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
tlEntering, .F., pcPrintID, this.oUser.cUserID,
this.oClient.cClientName, STRTRAN(_screen.cAppName,'\','\\'))
this.iLicenseKey = loLicense.iLicenseKey
IF this.iLicenseKey < 1 THEN && problem
llOK = .F.
loLicense.ShowMessage()
ELSE
llOK = .T.
ENDIF
ELSE && exiting software; release license
loLicense =
NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
tlEntering, this.iLicenseKey, pcPrintID)
IF loLicense.lProblem THEN
llOK = .F.
loLicense.ShowMessage()
ELSE
llOK = .T.
ENDIF
ENDIF
It doesn't instantiate.
Does it have to be an OLEPUBLIC class? I'm not doing that currently:
DEFINE CLASS MBSS_Licensor AS Session
I'm trying to avoid the registry; I just want to plunk the DLL into the
App's folder and have it reference it from there.
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/9de90ca62ecb6b84103e65b87f408...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 VFP9T.DLL.
There is the Single-threaded COM DLL as another option. I believe it
does
not require the VFP9T.DLL.
Yeah I agree it shouldn't be an EXE since no UI. I had tried the DLL
approach but for some reason it didn't work. It's not an OLEPUBLIC
class (at least not yet); it's just a Separator class (to be
lightweight, although in today's world, nobody would notice the
difference between a Separator and Session or Custom class).
I was trying to invoke it this way:
IF tlEntering THEN
loLicense =
NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
tlEntering, .F., pcPrintID, this.oUser.cUserID,
this.oClient.cClientName, STRTRAN(_screen.cAppName,'\','\\'))
this.iLicenseKey = loLicense.iLicenseKey
IF this.iLicenseKey < 1 THEN && problem
llOK = .F.
loLicense.ShowMessage()
ELSE
llOK = .T.
ENDIF
ELSE && exiting software; release license
loLicense =
NEWOBJECT("MBSS_Licensor","MBSS_Licensor.prg","MBSS_Licensor.exe",.F.,
tlEntering, this.iLicenseKey, pcPrintID)
IF loLicense.lProblem THEN
llOK = .F.
loLicense.ShowMessage()
ELSE
llOK = .T.
ENDIF
ENDIF
It doesn't instantiate.
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/531c7d97a5bff03ab52213724e59b...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
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 do not want this code reverse-engineered so I don't want to > distribute the VCX nor make an .APP (as you can view code in the .APP). > I want to be able to instantiate an object of this class and use it to > validate some things like login and license validation. > > tia, > --Mike > 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 VFP9T.DLL. There is the Single-threaded COM DLL as another option. I believe it does not require the VFP9T.DLL. Tracy Pearson PowerChurch Software ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/001b01d24b5c$6a67aee0$3f370ca0$@powerchurch.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
