Author |
Message |
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Wed Sep 25, 2002 5:50 pm
Post subject: ProjectInfo
|
|
Parents:
VB Header
[vb:kijcnate]- Const MAX_PATH = 260 ' UNICODE Characters
-
- Type tProjectInfo
- lTemplateVersion As Long ' 0x000 (000d) VB compatible version
- aObjectTable As Long ' 0x004 (004d) Pointer to ObjectTable
- lNull1 As Long ' 0x008 (008d)
- aStartOfCode As Long ' 0x00C (012d) Pointer to the start of some Assembly listing
- aEndOfCode As Long ' 0x010 (016d) Pointer to the end of some Assembly listing
- lDataBufferSize As Long ' 0x014 (020d) Size of Data Buffer
- aThreadSpace As Long ' 0x018 (024d)
- aVBAExceptionhandler As Long ' 0x01C (028d) Pointer to VBA Exception Handler
- aNativeCode As Long ' 0x020 (032d) Pointer to the start of RAW Native Code
- uIncludeID(MAX_PATH * 2 + 7) As Byte ' 0x024 (042d) VB Include Internal Project Identifier
- -> (260 + NullTerm) * 2 [unicode] + "*A"
- -> 528 bytes
- aExternalTable As Long ' 0x234 (564d) Pointer to API Imports Table
- lExternalCount As Long ' 0x238 (568d) Number of API's imported
- ' 0x23C (572d) <-- Structure Size
- End Type
[/vb:kijcnate]
Related Items:
Object Table
Note:
This structure is syncronized with the structure database. If editing this structure please update the structure database as well. Thank you.
Last edited by MrUnleaded on Mon Sep 06, 2004 12:03 am; edited 17 times in total
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Wed Sep 25, 2002 8:33 pm
Post subject:
|
|
this is what i've so far:
Code: | Private Type tProjectInfo
...
CallStartOpCode As Long '+C
'it points to a very strange string with 4 bytes, _
also check the CCh bytes before, it's all strange _
and can be deleted
CallStartAddress As Long '+10
'the same as the first, but this one points a few _
bytes after the first one
..
aNextSection As Long '+18
'points to location in the next section for some stupid reason
aBeginData As Long '+1C
'points to the data before the Address of Entry Point
aNativeCode As Long '+20
'points to the native code start
ProjectLocation As String '+24
'unicode location of the VBP-file, started with *\A [?? bytes]
End Type
|
anything wrong?
[Edit: Removed unnecessary items from the structure] _________________ One thing only I know, and that is that I know nothing. (Socrates)
Last edited by _aLfa_ on Mon Aug 02, 2004 12:01 am; edited 2 times in total
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Thu Sep 26, 2002 1:14 am
Post subject: aLfa's version
|
|
[="_aLfa_":2iifkloe] Code: |
CallStartOpCode As Long '+C
CallStartAddress As Long '+10
aNextSection As Long '+18
aBeginData As Long '+1C
ProjectLocation As String '+24
| [/:2iifkloe]
Anyone want to verify these items? i agree with the rest of them
Last edited by MrUnleaded on Tue Jan 06, 2004 12:25 am; edited 1 time in total
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Fri Sep 27, 2002 1:18 pm
Post subject:
|
|
[="_aLfa_":2aqqnvuv]'points to location in the next section for some stupid reason[/:2aqqnvuv]
Why, its a linked list of course
I can vouch for "ProjectLocation" and "aNextSection".
alfa, maybe you can expand on your reasoning for the naming of the other nodes?
MrU: You beat me to it you biatch!
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Fri Sep 27, 2002 4:18 pm
Post subject:
|
|
[="moogman":blmlfozm]alfa, maybe you can expand on your reasoning for the naming of the other nodes?[/:blmlfozm]some reference from a post of Sarge in http://www.decompiler.com
but i dont remember what post it is _________________ One thing only I know, and that is that I know nothing. (Socrates)
Last edited by _aLfa_ on Mon Aug 02, 2004 12:03 am; edited 1 time in total
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Sat Sep 28, 2002 12:57 am
Post subject: ;)
|
|
[="moogman":3oat1zjq]
MrU: You beat me to it you biatch![/:3oat1zjq]
Hehe
Ok I updated aNextSection and aProjectLocation.....
You guys may want to run through it and check it again
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Sat Sep 28, 2002 12:47 pm
Post subject:
|
|
Add on:
Code: | Unknown3 As Integer
Unknown4 As Integer |
Now strictly, they may always be constant and not useful, but it still makes my mapping function fill up the space nicely. I get sections directly after sections when adding these two integers
Also, it may be useful to add in some constants that correspond to data in the structures:
Code: | Private Const IMAGE_PROJECTINFO_SIGNATURE = &H1F4 ' F4 01 00 00
If ProjectInfo.Signature = IMAGE_PROJECTINFO_SIGNATURE Then
' Structure is valid, carry on |
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Mon Sep 30, 2002 2:00 am
Post subject: Re: ProjectInfo
|
|
[="MrUnleaded":3nacymd0] aProjectLocation As Long' 0x24
Flag2 As Integer ' 0x28
Flag3 As Integer ' 0x2A
' 0x2C <- Structure Size[/:3nacymd0]
gosh you guys are supposed to be checking these this isnt correct
Ive made the changes....ProjectLocation is an offset....and an Integer....which changes the remaining addresses and structure size
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Sat Nov 02, 2002 3:02 am
Post subject: Re: ProjectInfo
|
|
[="MrUnleaded":3gyaopbv]Parent: VB Header
Signature: &H1F4
Code: | Private Type tProjectInfo
Signature As Long ' 0x00
aObjectTable As Long ' 0x04
Null1 As Long ' 0x08
Address1 As Long ' 0x0C
Address2 As Long ' 0x10
Flag1 As Long ' 0x14
Address3 As Long ' 0x18
Address4 As Long ' 0x1C
aNativeCode As Long ' 0x20
oProjectLocation As Integer ' 0x24
Flag2 As Integer ' 0x26
Flag3 As Integer ' 0x28
' 0x2A <- Structure Size
End Type |
Related Items:
Object Table [/:3gyaopbv]
Signature As Long ' 0x00
aObjectTable As Long ' 0x04
Null1 As Long ' 0x08
Address1 As Long ' 0x0C SUPPOSED to be the "Beginning" of the pcode section.. maybe it's only for native.. I forget.. sorry
Address2 As Long ' 0x10 This is the OPPOSITE of the other one... the end.
Flag1 As Long ' 0x14
Address3 As Long ' 0x18 If I'm not mistaken, this is for the thread space or reserved memory to work it's magic. There may be some vtables stored here, and vb does its work somewhere around here.
Address4 As Long ' 0x1C Pointer to VBAExceptionhandler
Also the end of this structure is (I believe) MUCH longer than what was indicated. I've always considered it as 0x1f4 long.. dunno i could just be stupid i guess
Sorry if all of this has already been figured out, but i'm just starting to go through all of this
joe
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Sun Nov 03, 2002 3:01 am
Post subject: Re: ProjectInfo
|
|
[="josephCo":2vokitd9]Sorry if all of this has already been figured out, but i'm just starting to go through all of this
joe[/:2vokitd9]
if the first post isnt modified...then no one disagreed or added to what was posted
About the size...i have to disagree....
goto:
./files/2_1035406661.html
the beginning of ProjectInfo is at 0x1276
and the end is at 0x12A6
the project Location begins at 0x12A7 [which is referenced by oProjectLocation].... so....i believe that the structure size is as previously defined _________________ -MrU
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Sat Dec 07, 2002 11:57 pm
Post subject:
|
|
The length of my ProjectInfo is 0x2A (as is MrU's heh). The reason for this, is that most (if not all?) of the time, the OriginalPathName, pointed to by oOriginalPathName from ProjectInfo. This gives the absolute maximum boundary of the structure. JoCo noted that he thought the structure was 0x1F4. Well, we can see that if you dont include the original path name (which, I think is null-terminated variable length) then it is merely 0x2A. If you do include the filename then it is of variable length, which is Bad Thing(tm) heh.
I've also done a few other tests to probe the length of this structure *including* the length of the filename... and so we come to what im thinking now. It seems that the size could be ludicrously large... 0x23C bytes (LoL). It seems to fit (MrU, try changing your size of that structure to colour in a 0x23C size block and you'll see it fits nicely). The old stuff still works within the boundaries of the structure (the offset to the project path for example). But why are there so many nulls? Could they be padding for a maximum filename length? Also, what is the seemingly address-like number leading to -0x4 bytes from the "end" and the other numbers (mainly null) at the end?
joCo: What else have you documented past where we have stopped? I know you'll have the filename in your type, but what about after? Theres a difference of 458d bits between our structures. 458/2 = 229. _MAX_PATH = 260 (ie the maximum possible path length). So if you are considering the path length to be static, then your structure is too short because of large filenames.
Now, a little more pondering made my brain come up with this. Tell me if it makes sense...
We have our original structure. We then have a constant-length string placeholder (namely, _MAX_PATH * 2 long because its unicode).
So lets add that on. We now have a "structure" length of
0x232 bytes long. Do we get any overlaps? Not in my experience... maybe this needs more investigation. But it sure explains all those nulls!
But then we get a "gap" in the structures of 8 bytes.
### SKIP TO THIS BIT IF YOU'RE LAZY ###
(Bit useless now since you've probably read my explaination first hehe)
I therefore propose this:
Add on to the structure:
Unicode_OriginalPath(MAX_PATH * 2) As Byte
UnknownAddress As Long
Flag4 As Integer
Flag5 As Integer
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Sun Dec 08, 2002 1:19 am
Post subject:
|
|
Re your question:
"Also, what is the seemingly address-like number leading to -0x4 bytes from the "end" and the other numbers (mainly null) at the end? "
This is the pointer to the external library declarations (DECLARES). The number after it is the count. (or, maybe it is the other way around). This takes you to that crazy set of flags (0x07) that I had pointed out in some post a while back; this is a "type" flag, where 0x07 (umm, it's really 0x0000007) indicates the DECLARE. There is also a 0x06 flag, but I don't remember what it indicates;I'll have to check my notes
Also, working backwards, there is a group of data that has something related to the number of modules....Again, I'll have to check my notes.
The size is more like 0x250,an even hex number( if I remember correctly), but if you take your 0x232 and add the missing 8 bytes, you come up with 0x240, which is obviously an even hex number. So, it may be that 0x240 is right....Wow, yet again I'll have to check my notes.
I guess this leads us into resolving the size issue that I mentioned in the "corrections" section. This is good, two problems solved with one thread.
Sarge
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Sun Dec 08, 2002 1:56 am
Post subject:
|
|
Im sure of this: It cannot be more than 0x23C . You get structures going over each other otherwise. Hehe, 0x23C is an even hex number! (I know what you meant...). eg. in commonapp (1) for example, you get crossovers with the Object table (at 0x14B8).
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Mon Dec 09, 2002 3:52 pm
Post subject:
|
|
[="sarge":1h6gbbqz]Re your question:
"Also, what is the seemingly address-like number leading to -0x4 bytes from the "end" and the other numbers (mainly null) at the end? "
The size is more like 0x250,an even hex number( if I remember correctly), but if you take your 0x232 and add the missing 8 bytes, you come up with 0x240, which is obviously an even hex number. So, it may be that 0x240 is right....Wow, yet again I'll have to check my notes. [/:1h6gbbqz]
dang....i leave for two days ad you guys go at it hehe....
ok well sarge you made a math error 0x232+8=0x23A....hex rememebr
The Declares cool....something i needed hehe
btw: thanks for updating the struct Moog _________________ -MrU
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Mon Dec 09, 2002 4:21 pm
Post subject:
|
|
Last item:
So, we have this:
Signature As Long ' 0x00
aObjectTable As Long ' 0x04
Null1 As Long ' 0x08
aStartOfCode As Long ' 0x0C
aEndOfCode As Long ' 0x10
Flag1 As Long ' 0x14
ThreadSpace As Long ' 0x18
aVBAExceptionhandler As Long ' 0x1C
aNativeCode As Long ' 0x20
Flag2 As Integer ' 0x24 *
Flag3 As Integer ' 0x26 *
OriginalPathName( MAX_PATH * 2 ) As Byte ' 0x28 *
NullSpacer As Byte ' 0x233
aExternalTable As Long ' 0x234
ExternalCount As Long ' 0x238
* = we have decided on this, rather than:
OriginalPathName( MAX_PATH * 2 ) As Byte ' 0x24
Is this correct?
sarge
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Mon Dec 09, 2002 4:29 pm
Post subject:
|
|
If you have that, it'd have to be (MAX_PATH * 2) + (the size of the two integer flags). The size of the structure as you see it currently is correct - ie there are no overlaps. I was under the impression that we would keep it like that until we could decide otherwise. As always, I could be wrong...
Oh, and you're thing is a bit wrong - you missed out oProjectLocation, so check the original structure definition at the start of this thread...
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Mon Dec 09, 2002 4:34 pm
Post subject:
|
|
Well, to be honest, that's why I re-posted. I'm having a bit of confusion with oProjectLocation. I thought that oProjectLocation was the mistaken co-incidental data of the 0x2A that we later decided was text/flags, so, it should go away. (Maybe someone can put up a short hex dump of CommonApp from 0x127C to 0x14B7?) I hate to be a pain-in-the-a??, but I can't seem to see the forest for the tree.
sarge
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Mon Dec 09, 2002 4:37 pm
Post subject:
|
|
Oh, and yes, I like:
OriginalPathName( MAX_PATH ) As Integer ' 0x2A
better.
And, yes I agree the size is correct.
Sarge
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Mon Dec 09, 2002 4:39 pm
Post subject:
|
|
[="sarge":2mzuapvq]Oh, and yes, I like:
OriginalPathName( MAX_PATH ) As Integer ' 0x2A
better.
Sarge[/:2mzuapvq]
moog says if you put debug.Print BtyeArray() it pringts the string...
but Debug.Print IntArray() doesnt work...
so....i guess its a matter of semantics... _________________ -MrU
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Mon Dec 09, 2002 4:41 pm
Post subject:
|
|
[="sarge":tgfkv1ku]
Well, to be honest, that's why I re-posted. I'm having a bit of confusion with oProjectLocation. I thought that oProjectLocation was the mistaken co-incidental data of the 0x2A that we later decided was text/flags, so, it should go away. (Maybe someone can put up a short hex dump of CommonApp from 0x127C to 0x14B7?) I hate to be a pain-in-the-a??, but I can't seem to see the forest for the tree.
[/:tgfkv1ku]
Ok... The size of the structure now is proper. It lines up properly with sections after it in the file. The maths is presumably correct as well. oProjectLocation is not the same as Flag1/Flag2 - they are different sections of data. I named oProjectLocation as it was, because I thought it was the offset (starting at the start of the structure) to the project location. I didnt know what the flags were so I put them there and MrU changed the names to Flag1/Flag2 respectively. I think... (Heh, only kidding...(?))
[="sarge":tgfkv1ku]Oh, and yes, I like:
OriginalPathName( MAX_PATH ) As Integer ' 0x2A
better.
Sarge[/:tgfkv1ku]
Eek and DOUBLE EEK! I'll explain my reasons for having it as a byte array thus:
Basically, when you've read the data into the structure using
Get #fileNumber, ProjectInfo
You can then simply do
ProjectInfo.OriginalPathName()
and treat it as a string. eg.
Debug.Print ProjectInfo.OriginalPathName()
would print it to the debug window properly (there is no need for any type of conversion). Using As Integer will *not* enable us to do this.
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Mon Dec 09, 2002 5:51 pm
Post subject:
|
|
Then so be it!
Sarge
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Mon Dec 09, 2002 6:14 pm
Post subject:
|
|
Therefore, we have this:
(First hex is offset, second hex is CommonApp address)
Signature As Long ..................................' 0x00 127c
aObjectTable As Long............................ ' 0x04 1280
Null1 As Long......................................... ' 0x08 1284
aStartOfCode As Long................................. ' 0x0C 1288
aEndOfCode As Long......................... ' 0x10 128c
Flag1 As Long.........................................' 0x14 1290
ThreadSpace As Long..........................' 0x18 1294
aVBAExceptionhandler As Long................ ' 0x1C 1298
aNativeCode As Long............................. ' 0x20 129c
oProjectLocation As Integer....................' 0x24 12a0
Flag2 As Integer.................................... ' 0x26 12a2
Flag3 As Integer .................................. ' 0x28 12a4
OriginalPathName( MAX_PATH * 2 ) As Byte.. ' 0x2A 12a6
NullSpacer As Byte................................. ' 0x233 14af
aExternalTable As Long........................ ' 0x234 14b0
ExternalCount As Long........................... ' 0x238 14b4
Look ok?
sarge
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Tue Dec 10, 2002 7:10 am
Post subject: hmm....i dont get it
|
|
according to my output....CommonApp 1.0 has 1 external call....is this correct? cause i dont see any api's in the source.... _________________ -MrU
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Tue Dec 10, 2002 11:39 am
Post subject:
|
|
Well, in commonapp, the source is the source. If you dont see any APIs, then I dont either heh :/
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Tue Dec 10, 2002 2:01 pm
Post subject:
|
|
Well, I guess it's ok, so shouldn't this:
Const Signature = &H1F4 ' F4 01 00
Const MAX_PATH = 260
be this:
Const Signature = &H1F4 ' F4 01 00 00 <= Missing last byte of 4
Const MAX_PATH = &H105 <= New value AND needs /2
Sarge
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Tue Dec 10, 2002 2:04 pm
Post subject:
|
|
Trick question! There is always at least 1 external: MSVBVM60.DLL
Sarge
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Tue Dec 10, 2002 3:12 pm
Post subject:
|
|
Addedd the extra 00 for correctness.
I took the definition for MAX_PATH straight from the windows.h header file in the SDK, so presumably to keep compatibility it should stay that way? :/ The value should stay the same, otherwise the structure will break since the size is wrong, but feel free to convert it to hex if you want... it doesnt really make much difference mind
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Tue Dec 10, 2002 4:07 pm
Post subject:
|
|
Ok, whatever...you are now free to delete all the ^*&% I have posted trying to solve my problem...[which, if you are interested (and even if you're not) was that I started at the end of the struct and decoded backwards...this apparently cause me some math problems.]
Anyway, delete away! including that temp forum where you moved all the discussion stuff.
So, what's next.....structs for Declares? EventPointer and EventTable?
Sarge
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Tue Dec 10, 2002 4:27 pm
Post subject: Events first
|
|
[="sarge":338kkx9v]Ok, whatever...you are now free to delete all the ^*&% I have posted trying to solve my problem...[which, if you are interested (and even if you're not) was that I started at the end of the struct and decoded backwards...this apparently cause me some math problems.]
Anyway, delete away! including that temp forum where you moved all the discussion stuff.
So, what's next.....structs for Declares? EventPointer and EventTable?
Sarge[/:338kkx9v]
I think we need to do some clarification on the EventPointerTables...dont you?
I mean i got it down....i havent got into declares yet really... _________________ -MrU
|
|
Back to top |
|
|
|
sarge Moderator
Joined: 24 Sep 2002 Posts: 194
|
Posted: Tue Dec 10, 2002 5:16 pm
Post subject:
|
|
Yes, and thanks. "Thanks" because I think it would be more appropriate to fixup the old before we hit the new; further, "Thanks" for putting up with my BS; but mostly, "Thanks" for moving this stuff along....I admit I am excited about seeing the results and can't wait.
Ok, so I posted some ideas about the EventPointer and EventTable stuff..I guess the group should check it out and discuss?
Sarge
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Tue Dec 10, 2002 10:56 pm
Post subject:
|
|
[="sarge":1bia086b]Yes, and thanks. "Thanks" because I think it would be more appropriate to fixup the old before we hit the new; further, "Thanks" for putting up with my BS; but mostly, "Thanks" for moving this stuff along....I admit I am excited about seeing the results and can't wait.
Ok, so I posted some ideas about the EventPointer and EventTable stuff..I guess the group should check it out and discuss?
Sarge[/:1bia086b]
well i appreciate everyones help....without you guys it may have taken me twice as long to get where i am....
but yea...lets start with EventTable.....i posted my comments in the EventTable Topic... _________________ -MrU
|
|
Back to top |
|
|
|
MrUnleaded Site Admin
Joined: 21 Sep 2002 Posts: 385 Location: California
|
Posted: Wed Dec 11, 2002 6:37 am
Post subject: just a hunch...
|
|
[="sarge":2jyjpnxq]Trick question! There is always at least 1 external: MSVBVM60.DLL
Sarge[/:2jyjpnxq]
perhaps that one external API call is the MsgBox function??
hopefully we will find out soon _________________ -MrU
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Wed Dec 11, 2002 9:13 am
Post subject:
|
|
Well, not really. What Sarge is saying, presumably, is that MSVBVM60.DLL is *always* included as a reference Otherwise, where would it know where to look for all the standard functions (yes, MsgBox etc). I guess, you could view all functions as being external references - that way, you'd not have to process the seperately (Heh, well, why bother? We can tell that its not "external" - ie its not from MSVBVM60.DLL, because "external" declares are wrapped in a VB error handling routine, whereas internal ones arent if my memory serves me correctly.. GetLastDLLError or something is always called after the actual external API). It could be wise then to have in your second parse, a flag for each call telling your third parse whether its an external event or not - if it is, you can find it out, otherwise you know where to look (MSVBVM60.DLL)!
|
|
Back to top |
|
|
|
Anonymous New User
Joined: 10 Feb 2008 Posts: 0
|
Posted: Wed Dec 11, 2002 10:42 am
Post subject:
|
|
Just going through this again: It may be fine to note that aNativeCode = 0 when PCode and <> 0 when Native. Maybe, then IsNativeCode would be more appropriate. Just a thought...
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Mon Aug 02, 2004 2:08 pm
Post subject:
|
|
I fixed the structure to reflect Microsoft standards in the OriginalPathName size because max length is 260 null terminated unicode characters.
(0 to 259) * 2 = 520 bytes
Null * 2 = 2 bytes
This adds up to 522 bytes. _________________ One thing only I know, and that is that I know nothing. (Socrates)
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Tue Aug 10, 2004 2:33 pm
Post subject:
|
|
I was playing arround with this structure and I found out that ThreadSpace points to the very beggining of the next section (.data) if the exe was compiled with p-code, and it points to the very beggining of the next section + 8 bytes if compiled with native code.
I may be wrong, but this 'rule' worked for the exe's I tested on... _________________ One thing only I know, and that is that I know nothing. (Socrates)
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Wed Aug 25, 2004 5:34 pm
Post subject: Re: ProjectInfo
|
|
Code: | Private Type tProjectInfo
...
aNativeCode As Long ' 0x20 (32d)
oProjectLocation As Integer ' 0x24 (36d)
Flag2 As Integer ' 0x26 (38d)
Flag3 As Integer ' 0x28 (40d)
OriginalPathName(MAX_PATH * 2 + 1) As Byte ' 0x2A (42d) [0 to 259 + Null terminator] * 2 (unicode) = 522 bytes
...
End Type |
I propose another change to this structure:
* Merge oProjectLocation, Flag2 and Flag3 into OriginalPathName
* Rename OriginalPathName to something more suitable (because now its something like "*\A<insert path here>" wich is the kind of instruction VB uses when you want to insert another project in your current project as in group workspaces)
* And of course the size of this member should be changed to: 6 + (MAX_PATH + 1) * 2 [6 bytes for "*\A"] = 0 to 527 = 528 bytes
Tell me your opinions _________________ One thing only I know, and that is that I know nothing. (Socrates)
|
|
Back to top |
|
|
|
_aLfa_ Site Admin
Joined: 21 Sep 2002 Posts: 233 Location: Aveiro, Portugal
|
Posted: Thu Aug 26, 2004 5:29 pm
Post subject:
|
|
I've changed the structure to what I think it's correct.
I need some more feedback on lFlag1 wich I belive is some kind of buffer size, maybe to the data buffer?
aThreadSpace being here for some time, but I need someone to explain me it better, cuz I don't understand it yet.
Changed Signature to lTemplateVersion because this is almost the same as the "VB5!" VBHeader signature where 5 is the minimum VB compatible version.
And at last I done what I said in my last post, so read it _________________ One thing only I know, and that is that I know nothing. (Socrates)
|
|
Back to top |
|
|
|
|
|