Re: PostScript prologue [was: 16-bit versions of gnuplot doomed?]

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Fri, 27 Feb 2004, Ethan Merritt wrote:
>
>  
>
>>It occurs to me that we might use the approach of Adobe products
>>like FrameMaker.  The long PostScript prolog that is constant for
>>every output document is stored as a separate file in some appropriate
>>directory, and then copied into the output stream when a new 
>>document is being generated.
>>    
>>
>
>Yeah, that idea had been creeping around at the back of my mind, too.
>
>  
>
>>1) It doesn't take up any space in the source code module, which is
>>   what your DOS compiler doesn't handle well
>>    
>>
>
>At least part of the blame for that goes to the language itself.  There's
>no syntax in C to influence where string constants are to be stored.  
>If you look at the (slightly modified) definition of PS_header:
>
>	static const char GPFAR * const GPFAR PS_header[] = {
>	   "line of text\n",
>	   "line of text\n",
>	   /*...*/
>	  "last line\n"
>	};
>
>you'll find that there are two GPFAR markers for the array of pointers,
>i.e. it's a "far array" of "far pointers".  But I can't tell the compiler
>to put the *strings* themselves into a "far data" or "far code" segment.
>

Yes, that seems like an assembler controlled directive.

>I'm not quite through trying all possible tricks to get this through
>the compiler's limitations, though.
>  
>

Can you issue an assembler directive using the "asm()" command depending 
upon if it is DOS?  How many different assemblers are there for DOS? 
 (Borland, Microsoft)   And how different are there assembler commands 
for control memory location?  But that might still not do it, because 
controlling the string placement is the issue, right?

This is odd, I just grabbed an old Microsoft C book by Jamsa.  He has an 
example:

main()
{
   char far *str = "Message to display";
   str_display(str);
}

where the subroutine has the command

   printf("%c %p\n", str[i], &str[i]);

which ends up printing the memory values as

6CB2:0282 M
6CB2:0283 e
...

and so on.  So that seems to suggest to me that assemblers should be 
programmed smart enough to recognize that the strings declared with 
"far" pointers can be placed in far memory blocks.

Perhaps the C syntax above is conflicting.  Maybe by also declaring the 
pointer as "const", the assembler is forced to place the strings in the 
segment where constant memory is located; and that may be in the code 
segment.  As a wild guess, you might try removing the "static" and/or 
"const" qualifiers.

Dan