So this is the situation. Our company has its own standard codes and windows (for commonly used routines and for inheriting) that we use in developing applications. These "standard codes and windows" is saved in its own library (pbl). Normally when we deploy our software to the client we just compile it to pbd's and exe's, but this time our client wants also the source code of the software. The thing is we don't want our standard codes and windows to be visible when we give the source code to the client. So is there a way to encrypt (shield, hide etc...) the codes.
I hope someone can point me to where should I start researching.
The .pbls contain sources, resources and binaries, while the .pbd contain no source.
If you do not want to leak any source code, just give the .pbd and .exe files.
If you do want to give the source code of the application minus the source code of your standard library, give the all .pbl files but your standard library, and give the .pbd of the standard lib. Thus your client will even be able to recompile the app (providing that the standard lib object are called by, but do not call other pbjects from the application).
Please note that like Java, the PowerBuilder objects can be decompiled from binaries with the right tool.
I am not aware of a mean to encrypt PB source code, but there is the possibility to obfuscate the objects through PB-Protect. I never used it and I cannot tell more about it.
If they're actually looking for insurance should you disappear, perhaps a code escrow service might be acceptable? My company escrows our source at customer request as a paid-for contract line item, I think with Iron Mountain.
Related
I've been successfully using Vivado and the SDK to develop VHDL and C for the Zynq XC7Z010 on a Digilent Zybo board. I've also been using the GNAT GPS IDE to learn Ada targeted to an STM32F4 processor (using one of the supported development boards).
GPS also ships with a set of zynq7000 run-times targeted to the XC7Z020 (as far as I can tell). Having looked through the BSPs for these target I believe that the code generated should also run on the XC7Z010 as the ARM cores appear to be the same. It may turn out that there are differences, in which case I will have a go at building a specific run-time based on the existing zynq7000 BSP (Adacore have documented this process and give an example for generating a new STM32F4 BSP).
My main problem is I'm not sure how to load and run the generated Ada elf file on my Zybo. I have tried to generate a BOOT.ini file containing a FSBL (built with the SDK and using my exported hardware from Vivado), a bit-stream and the Ada elf file (The the Zybo has an MicroSD interface that can be configured as a boot device, this works perfectly with a bit-stream and C elf produced via Vivado / SDK).
Anyway, this didn't work... I'm guessing that it might be a linking issue, or a boot loader issue, or similar. With my current level of knowledge I'm just not sure at this stage.
Any advice or pointers would be greatly appreciated!
It turns out that my BOOT.ini was fine, the problem was related to accessing custom AXI registers defined in my bit-stream. If I remove these references from the Ada the generated ELF file works perfectly. For example, printing over the Zybo's VCP using Text_IO.Put_Line(), using Ada run-time delay and Clock operations etc.
For some reason the AXI interface isn't working when I boot an Ada ELF file. If I substitute this for the equivalent C, then all is well.
This particular problem is currently unresolved, but not related to my original question!
(It might be that the Ada run-time is relying on the FSBL or u-Boot to have initialised this, not sure. Feel free to comment if you know, I'll also add a comment when I resolve this)
**** Update ****
Here is some additional background and a description of what I had to do to get my custom AXI IPs to work.
The provided AdaCore BSP (Board Support Package used to build the run-time) is targeted at the Xilinx XC702 development board. I'm using a Digilent Zybo (the older version). The two boards use different Zynq parts, the XC702 is based on a XC7Z020 and the Zybo uses a XC7Z010 (there is a new version with a XC7Z020 option).
I followed the AdaCore instructions (available on their web site) and built a BSP specifically for the Zybo. Initially I just updated the clock details as the Zybo runs at a different speed and then verified that the Ada delay function worked correctly (provided as part of the Ravenscar run-time built from the updated BSP). However, my custom AXI IPs still didn't work...
To cut a long story short, the Ada run-time contains as assembly file called start-ram.S that amongst other things sets up the MMU. There is an include file called memmap.inc that contains the actual MMU page definitions as a series of .long directives. I had to update the AXI_GP0 address entry by editing the particular directive to,
.long 0x43c10c16 # for 0x43c00000, axi_gp0
Previously it was set to 0x00000000 # for 0x43c00000, *none*. These entries are decoded within start-ram.S and then used to configure the MMU (the top 12 bits set the page and the remaining bits are chopped up and used as page config).
So, once I edited this file in my Zybo BSP and re-built the run-time, the IPs became accessible from the PS and worked as expected. This all took a while to figure out, but was worth it as I learn loads whilst exploring the dead ends!
I hope this helps someone in the future, I also highly recommend Ada for Zynq development especially if you ultimately need DO-178 certification, or similar.
I've developed a program and I am trying to make this program work with a controllable light source manufactured by some other company. I've emailed the company and they have agreed to send me their external library as a DLL.
I have developed all of my software using Qt 4.8.1 and it has been compiled using MSVC2008.
The controllable light's DLL was compiled in Visual Studio 2008 and was written in either C++ or C# (the manufacturer is uncertain). All I have been given is the DLL and a text file saying that I must:
Add the DLL as a reference to my project
Add using LightName; to the top of the class
Instantiate an instance of the object like so: LightName *ln = new LightName();
Call function void turnOn() with the newly created LightName instance.
Firstly, I find it odd that an external library requires me to instantiate an instance of their object especially when its for a simple piece of hardware.
Secondly, the other company has provided me with no interface files.
My question is:
How can I possibly link to a C++ DLL and expose the functions nested in this library without having an interface header file in a Qt environment? Is there someway to make an interface for an external library?
I have already attempted using QLibrary and doing the following:
QLibrary myLib("mylib");
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
myFunction();
However, this doesn't work because the DLL I was given was not a C DLL and I have no interface so Qt doesn't have a clue about what symbols it needs to resolve.
I've attempted to display all the definitions exported from my DLL using the dumpbin /EXPORTS command. Unfortunately this was unable to produce anything. I was hoping that I would get some sort of mangled C++ from this that I could then unscramble to make my own header.
I've attempted to use the dependency walker(very useful tool) however it couldn't resolve any symbols to give me some function definitions.
QLibrary only helps you if the library has functions exported as C symbols. If that is C++ you can dump the symbol table and look if that is sufficient for you. Names must be demangled: try to look for dumpbin or similar. It is however possible that you can't do this, it depends on how the symbols have been defined. In that case you'll have to ask for the header: read this.
Well it's absolutely legal to ask you for "instantiating an instance of their object". It's been simply their design decision to make the dll interface object oriented (as contrary to plain extern "C"). QtCore.dll is just someone else's DLL too, and you are instantiating their objects all the time.
But it also means that you will have harder time to call the DLL. The symbols are not "C" symbols (you can't export class that way) so QLibrary can't do anything for you. You can try dumpbin /EXPORTS from the DLL and then tediously unmangle them to reconstruct the class declaration. Luckily there are tools to help you (even online)
But not providing a header file for such DLL is completely dumb in the first place.
I am trying to trace a possible memory leak in a very large ASP.NET application. I am trying to familiarize myself with WinDBG before attempting to use this tool in the live environment.
I have followed the instructions in the following article, which I found very helpful: http://humblecoder.co.uk/uncategorized/spotting-a-memory-leak-with-windbg-in-net. I am able to create a "memory dump" file of the ASP.NET process and show that the delegate is causing the memory leak as specified in the article. I refer to the paragraph in the article that starts: "Next we need the symbols". I did not add the symbol files using File\Symbol File Path; in WinDBG and yet I still seem to be able to debug the application and follow through the remaining steps of the article. Are symbol paths not required with an ASP.NET application?
Because .NET assemblies contain metadata, including the name of every method and its parameters, symbols aren't necessary to obtain a readable stack trace of a managed thread.
One thing symbols can provide is the file name and line number of each statement, so you can more easily figure out which frames in the stack trace correspond to which lines in your source code.
As Michael says symbols are not strictly necessary for managed code as most of the relevant information is available at runtime as metadata, but if you're digging into native code it is very useful to have symbols.
For many scenarios you can just do .symfix which will tell WinDbg to use Microsoft's public symbol server. That will give you access to symbols for all the CLR and Win32 specific calls in your code. Remember to do a .reload if you set the path.
If your code includes native non-Microsoft assemblies as well, you need to append the location of the corresponding PDB files to the symbol path. Use the .sympath command for that.
To troubleshoot symbol loading use the !sym noisy command.
For more information see this.
Dear all, I am working on flex3 and want to update my application by flex3 autoupdate. When my installed application runs, my checkUpdate function calls the autoUpdater code. It starts but when it reaches to 100%, it shows this error: "There was an error downloading the update. Error# 16824"
My mxml code is here http://tinypaste.com/92138b and server xml code is here http://tinypaste.com/e3792
Please guide me.
Many Thanks
Google is your friend for this one; it looks like you forgot to update the application descriptor version number in the updated version on the interweb.
http://dezeloper.wordpress.com/2010/01/21/adobe-air-updater-error-16824/
I was unable to see your code as our work router blocks tinypaste. That said, however, I can tell you that air updates done via the ApplicationUpdater class are all based upon the updater xml file that you create/copy-out-there, and the xml file used for the compiler that sets the filename, version, application ID, etc. (most of which is used for the exe-compiler/exe-wrapper that facilitates the "bridge" between the OS and your compiled actionscript code). This link, might help: dezeloper.wordpress.com.
All-in-all keep debugging. The ApplicationUpdater class is one that was relatively well-written and is pretty self-explainable... once you get past this bug, there are a couple more that might be a sync-the-xml-text pain-in-the-butt. For example... I can tell you that in AIR 1.0 (and this may still be true in recent releases) if you made a change to your application xml file, and you're compiling from eclipse/flexBuilder/flashBuilder, you had to "project > clean" for those xml options to get picked up.
Best of luck,
Jeremy
Is it possible to find all interfaces (classes, parameters, ect..) normally registered with Component Object Model's (COM) TypeLib even though the TypeLib is completely empty? If so how would you go about doing this? I believe another term for this is an "Anonymous COM". I am sure that accessible interfaces exist for this COM because i have an application that is using a class that isn't listed in the TypeLib.
If the type library is blank, then there is no way that you can find information about the types in a COM library.
You need at least a coclass entry in the typelib to find an implementation of IUnknown.
If you have that, then you can actually create instances of the class and then call QueryInterface on IUnknown for the IDispatch implementation (if one exists).
If an IDispatch interface exists, you can then call GetTypeInfo to get information about the interfaces that are implemented.
If you need to make late-bound calls to IDispatch, then you will need to call the Invoke method.
Note, you mention the type library, but it is common practice for in-process COM servers to embed the type library in the dll that is the implementation of the types represented in the library. Are you sure that you haven't checked that as well? Or are you sure you have the type library and it is indeed blank?
If the type lib is indeed blank and the dll doesn't contain it, it's completely possible that the type lib was "private" in the sense that other clients were compiled against it. COM doesn't need a type-lib at runtime necessarily. The pattern for exposing IClassFactory interface implementations is to export a standard DLL function with a well-known signature.
One could easily call LoadLibrary, then call GetProcAddress and cast the result to IClassFactory. From there, they would use the private GUID and IID that they know (not from the type library) as well as the COM interfaces that they have defined privately and work from there.
The only reasoning I can think of for something like this is a form of obfuscation and/or addressing privacy/security concerns, only allowing clients the producer of the server approves of to call it.
It doesn't help you, but could explain why you are seeing a type library with no information in it and at the same time, see other clients consume the library.
Not using a type library in COM programming is fairly common. Any scripting language does, it uses IDispatch to discover supported methods and properties at runtime. IDispatch::GetIDsOfNames() or IDispatch::GetTypeInfo() gets that ball rolling. This is called late-binding. It is slow, but that doesn't matter in a scripting language.
Another standard way is through header files generated by MIDL from a .idl file that describes the interfaces and coclasses. You'll find many of them in the Windows SDK include directory, mshtml.h for example. But this is suitable only to unmanaged C/C++ code.
Using COM without a type library in a managed language like C# is difficult but not impossible. VB.NET is the better language, it supports late binding out of the box. C# will get better when version 4.0 arrives, it has a new "dynamic" keyword.