At 16:37 2002-11-14 -0500, you wrote:
Are you using a read-only global that's defined in a code segment (pcrelconstdata) or defined in the data segment? If its code, those can only be directly referenced from code that's in the same segment -- to see them from other segments, you will need to call a utility function in the segment with the variable that will return a pointer to the item.Not quite certain what that statement means unless you are referring to the article in which it mentions the "no-global launch". However, what it may have to do with is what I am experiencing now...When I want to access a global variable that is not in the first segment, I get garbage for all of the values in the global. However, when I move the global in question to the first segment, the values it contains are correct. There has to be a way around this since five of my six segments are nothing but globals that are placed in a const pointer array from the first segment. The globals are simply used as data. Perhaps the way to do this is to stick all of the data into database records. If I can't stick with the multi-segmented global angle, do you recommend going with writing everything to a .pdb file or do you recommend another angle? And if you do recommend writing to a .pdb file, is there a way to do so through Win32 programming? In other words, are there API calls that I can make from a Win32 program that will generate a valid .pdb file -- maybe something analogous to DmWrite?
This would explain your problem... you see, data is code is accessed by adding or subtracing a value from the program counter. If your data is in the same segment as the code that's executing, this works fine, since the distance from the current instruction to the data is a constant value that's known at compile time. However, if the data is in another code segment, this offset can't be known until your app actually starts running. The linker will setup a jumptable in data to allow one segment to call another (this is built at application start time), but the JT only works for going code-to-code, which is why I suggest added an accessor routine to your "data as code" segments that will return a pointer to the various data items. Once you've gotten the absolute address at runtime, it won't change until your program exits.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
--
For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
