🚀 go-pugleaf

In article <TGL.96Jan5065424@netcom21.netcom.com>, tgl@netcom.com 
said:
>Just change the definition of boolean in jmorecfg.h.  There's 
specific
>advice to do that for Windows apps in install.doc, btw.

  This I did and it solved a LOT of problems. :) Thanks.  I didn't 
see the reference in install.doc.

>> API functions (i.e. CreateFile instead of fopen, ReadFile 
instead of the 
>> JFREAD macro, HeapAlloc instead of malloc) and everything 
appears to work
> 
>> until I try to allocate a buffer with the jpeglib's memory 
allocation 
>> functions.  Then I get an invalid page fault.
>
>Hm.  That one I don't have an answer for offhand.  Which memory 
manager
>back end are you using --- jmemnobs.c, or something more complex?
>

  Jmemnobs.c.  After much fudging around with the code I finally 
got it going. I'm not sure exactly what change made the difference. 
 I've had so many problems getting this thing to compile my head is 
spinning.  I think I'm going to go get VC++ 4.0. :)  

  Unfortunately I still can't get the library to work with my 
current application.  I made a short and quick Windows app to test 
how the library functions under the GUI and now I can get it to 
work every time with that, but if I try to integrate it into the my 
major project it chokes like it always did.  I still get the 
strange structure interpretation problems.   I've changed every 
compiler setting I can think of (including making sure the 
alignment options match like someone mentioned) and I've concluded 
that it must be something in one of my includes because no change I 
make seems to fix it.  Checking the cinfo structure after it comes 
back from jpeg_read_header shows that cinfo.image_width and 
cinfo.image_height are correct, however almost every field with  
"output_xxxx" is way off, either 1, 0, or some rediculous number 
like 7988774.  Of course this causes every other call after that to 
choke and I end up with an invalid page fault in Kernel32.dll.  
This library is pretty picky! :)  

>Yes, it is.  Here's the latest dope from the current version of 
install.doc
>:
>Borland C++ 4.5 fails with an internal compiler error when trying 
to compil
>e
>jdmerge.c in 32-bit mode.  If enough people complain, perhaps 
Borland will 
>fix
>it.  In the meantime, the simplest known workaround is to add a 
redundant
>definition of the variable range_limit in h2v1_merged_upsample(), 
at the he
>ad
>of the block that handles odd image width (about line 268 in v6 
jdmerge.c):
>  /* If image width is odd, do the last output column separately 
*/
>  if (cinfo->output_width & 1) {
>    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* 
ADD THIS
> */
>    cb = GETJSAMPLE(*inptr1);
>Pretty bizarre, especially since the very similar routine 
h2v2_merged_upsam
>ple
>doesn't trigger the bug.

  Thanks for the tip!  I'll make the changes.  I don't know if you 
are aware of this,  but if you use the BCC32a instead of plain 
BCC32 it will compile without a hitch.  The BCC32a is for Pentium 
scheduler support and of course has a different back-end than 
BCC32.


  I haven't gone through all the code yet, but all I really need to 
do is decode a JPEG file to its normal dimensions (no scaling) at 
24 bits per pixel.  How difficult would it be to strip out 
everything except support for that.  At a quick glance it seems 
everything is tightly integrated.  I also don't need any of the 
virtual array functions since I've got over a 2 gig virtual address 
space.

           -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------