Closed GoogleCodeExporter closed 9 years ago
Thanks, good suggestion. Thanks for the patch.
I will enhance it so that it's not limited to Windows environment but can also
operate in *nix and others. Most
likely I'll just provide with a way of setting up patch where to look for
imported DLLs and give an option when
importing the file to resolve ordinals or not, as it might increase the loading
time and might not be desirable in
all use-cases.
Original comment by ero.carr...@gmail.com
on 28 Jun 2008 at 10:09
The increase of the loading time could be reduced if
the export structure was actually a dictionary, where
the keys would be the ordinal indexes and the related
contents be the associated ExportData structures.
We shouldn't need to read all the exports structure
any more to find a function by its ordinal. We would
need only access to the whole entity. (it is even
possible to give the user the opportuny of choice
with a function parameter for instance, or sth else)
What do you think of that structural improvment ?
Original comment by carre.ro...@gmail.com
on 28 Jun 2008 at 10:51
The new release in-the-works will allow to only process specific data
directories, so in the case of loading
additional DLLs only the export directory needs to be parsed, I think that
would be already a good improvement.
Original comment by ero.carr...@gmail.com
on 28 Jun 2008 at 11:01
Good morning Mr Carrera.
In the suggested code for pefile.py,
<code>
if exports_launched:
for current_symbol in exports_symbols:
if current_symbol.ordinal == imp_ord:
imp_name = current_symbol.name
break
</code>
should be replaced by :
<code>
if exports_launched:
for current_symbol in exports_symbols:
if current_symbol.ordinal == imp_ord:
if current_symbol.name:
imp_name = current_symbol.name
else:
imp_name = os.path.splitext(os.path.basename(
exports_file_path))[0].upper() + "_%s" % imp_ord
break
</code>
to ensure cases where export names are not explicitly specified.
Thanks.
Original comment by carre.ro...@gmail.com
on 1 Jul 2008 at 9:20
This functionality belongs outside the pefile module. Given that it runs on
multiple platforms the availability of
the necessary DLLs can't be taken for granted. The additional information can
be easily gathered by augmenting
pefile's output with the code snippets mentioned in the issue.
Original comment by ero.carr...@gmail.com
on 2 Jan 2009 at 1:03
Original issue reported on code.google.com by
carre.ro...@gmail.com
on 28 Jun 2008 at 9:36Attachments: