Re: Reverse Engineering Packages vs Project ?

Well so far I have create two projects to investigate this...

The same source code but two different projects.

One project includes the sources directly.

The other project uses a package which is build into it.

So far the disassemblies are exactly the same ;)

Which was kinda surprising since I build the package with debug options on
etc...

Then later I build project 2 (the one with package) with debug options
off... etc...

I was wondering about that... if I had to build special release/debug
versions of each package...

But I think delphi will recompile all packages if the debug options of the
project changes... is that true cause I am not sure... (it was just a small
test you know ;))?

Bye,
Skybuck =D

"Skybuck Flying" <nospam@xxxxxxxxxxx> wrote in message news:...
> Hi,
>
> What would be easier to reverse engineer:
>
> 1. An application which is build from units/sources files only.
>
> or
>
> 2. An application which is build from some units and packages.
>
> I think it's possible to build an application that consists out of an
> executable only and still using the packages... but how does this work
> exactly ? Or the packages simply added to the executable file and then
> simply loaded at an offset like a seperate package would be ?
>
> I think (external) packages are probably more easily reserved engineered
> than a project without packages ?
>
> For example a package could more easily reveal what api was used so that
> means somebody else could steal the api design !? or maybe even use the
> package etc.
>
> Is there anyway a c or delphi programmer could prevent somebody else from
> using DLL's which are delivered with programs ?
>
> Bye,
> Skybuck.
>
>


.

Relevant Pages

  • Re: cobbling a ComboBox
    ... suggest you have a look at the library source code (of Swing, ... package scratch; ... boolean shouldValidate = false; ... the String ought to be "scratch.CustomMetalComboBoxUI". ...
    (comp.lang.java.gui)
  • Re: Redhat and OpenSSL Manner
    ... It's equivalent to 0.9.7a as originally distributed by OpenSSL project, with security and bug fixes added to it by Red Hat. ... enhancements and new features might be backported from newer versions too if they are not introducing any compatibility problems (for example this is often done for kernel package in RHEL to support new hardware). ... If you look into the SRPM packages, you'll see that they contain original unchanged source code wich is the same version as the package version, and also bunch of patches that get applied to that source code prior to compilation. ...
    (RedHat)
  • Re: Linux Vs. FreeBSD
    ... > source code is annoyingly slow and relatively difficult when it cones ... > Elaborating on the whole binary compatibility thing, ... A better example would be Fedora ... You usually can't install a Fedora package on Suse or vice ...
    (comp.os.linux.misc)
  • Re: Linux Vs. FreeBSD
    ... > source code is annoyingly slow and relatively difficult when it cones ... > Elaborating on the whole binary compatibility thing, ... > install something intended for one distro on another, ... You usually can't install a Fedora package on Suse or vice ...
    (comp.os.linux.misc)
  • Re: VCLZip Pro 3.04
    ... bought up this package and bundled it as part of Windows, ... source code because we didn't want to have to deal with supporting it. ... NOT an "open source" development effort, ... > reason I have decided to make my software open source and for that reason, ...
    (borland.public.delphi.thirdpartytools.general)