old VB3 apps : info desperately needed, please help! 
Author Message
 old VB3 apps : info desperately needed, please help!

Hi,

i've got a question for you.

I have a copy of an old application, written in Visual Basic 3.

Now what's the problem:

Thsi application was created by a company called 'Execomp' .
They created one of the first issues from National Geographic Maps.
This is a 9-cd set with a lot of images.
Unfortunately, this company is 'dead'

What is my problem:

first of all, the software provided with the original cd's only runs
on 95 or 98.

this separate viewer that i downloaded a few years ago from

under winMe or win2000.
This app will run fine under w98/w95/NT4

So, now i can't view the images that are stored on the cd's

THIS IS MY QUESTION:


files are stored, and post the decoding routines? Or mail them to
me....

You can find the software, an a sample image + preview at:

http://www.*-*-*.com/ ~verhaag/bigview.html

Maybe this article can be of any help:
http://www.*-*-*.com/ %22national+geographic+maps%22+exec...

This download-link is dead
http://www.*-*-*.com/



Fri, 20 May 2005 23:54:17 GMT  
 old VB3 apps : info desperately needed, please help!
Unfortunately these are all 16-bit files.
That will also be the main problem for the errors you are getting.

So you need to search for a 16-bit VB De{*filter*} ...

Regards, J?rg


Quote:
> Hi,

> i've got a question for you.

> I have a copy of an old application, written in Visual Basic 3.

> Now what's the problem:

> Thsi application was created by a company called 'Execomp' .
> They created one of the first issues from National Geographic Maps.
> This is a 9-cd set with a lot of images.
> Unfortunately, this company is 'dead'

> What is my problem:

> first of all, the software provided with the original cd's only runs
> on 95 or 98.

> this separate viewer that i downloaded a few years ago from

> under winMe or win2000.
> This app will run fine under w98/w95/NT4

> So, now i can't view the images that are stored on the cd's

> THIS IS MY QUESTION:


> files are stored, and post the decoding routines? Or mail them to
> me....

> You can find the software, an a sample image + preview at:

> http://www.*-*-*.com/ ~verhaag/bigview.html

> Maybe this article can be of any help:

http://www.*-*-*.com/ %22national+geographic+maps%22+exec...
en&lr=&ie=UTF-8&oe=UTF-8&selm=a0fsbq%2499i%241%40slb0.atl.mindspring.net&rnu
m=1

- Show quoted text -

Quote:

> This download-link is dead
> http://www.*-*-*.com/



Sat, 21 May 2005 00:11:40 GMT  
 old VB3 apps : info desperately needed, please help!

Quote:

>Hi,

>i've got a question for you.

>I have a copy of an old application, written in Visual Basic 3.

>Now what's the problem:

>Thsi application was created by a company called 'Execomp' .
>They created one of the first issues from National Geographic Maps.
>This is a 9-cd set with a lot of images.
>Unfortunately, this company is 'dead'

My first guess is that the file is made up of a number of small images with some
"position" information to allow building a "view" from many small images instead
of one large one.  Considering the typical PC in the days of VB3, (640x480
display, 800x600 was "high res") and "fast" 486 processors, this seems a
reasonable assumption.  

JPEG is a very broad standard and JFIF is just one format that meets the
requirements.

The following description of the JPEG format was taken from the "readme" file in
a zipped archive of the actual JPEG standard.  As you browse through one of the

There are probably two ways of creating a new display program.

1. Create a binary file reader to extract the images and their position info.
Use a set of imageboxes to display the related images to make a larger image.

2. Create the binary file reader to extract the images and save each one to a
file, either with the coordinates in its name or with a generic name
(group011image04.jpg) and a database that contains the file name and position
data.  Load a set of imageboxes with related small images to get the larger
image.

In either case, you'll need the position data to know which image is next when
scrolling (in any direction) and to determine when you're at the edge of the big
image.  There may be "the next file is" type information in the image file, the
program code, or an associated database or datafile (xxx.dat).

This is an interesting project, but I have a paying client with deadlines...

=============================
A technical explanation of the JPEG/JFIF file format,
written by Oliver Fromme, the author of the QPEG viewer
-------------------------------------------------------
Legal NOTE: The legal rules mentioned in the Disclaimer in top of this file
apply also to the following informations so neither Oliver Fromme, neither I
can be held responsible for errors or bugs in the following informations.

The author of the following informations is:
   Oliver Fromme
   Leibnizstr. 18-61
   38678 Clausthal
   GERMANY

JPEG/JFIF file format:
~~~~~~~~~~~~~~~~~~~~~~

  - header (2 bytes):  $ff, $d8 (SOI) (these two identify a JPEG/JFIF file)
  - for JFIF files, an APP0 segment is immediately following the SOI marker,
        see below
  - any number of "segments" (similar to IFF chunks), see below
  - trailer (2 bytes): $ff, $d9 (EOI)

Segment format:
~~~~~~~~~~~~~~~

  - header (4 bytes):
           $ff     identifies segment
                n      type of segment (one byte)
           sh, sl  size of the segment, including these two bytes, but not
                           including the $ff and the type byte. Note, not Intel
order:
                           high byte first, low byte last!
  - contents of the segment, max. 65533 bytes.

 Notes:
  - There are parameterless segments (denoted with a '*' below) that DON'T
        have a size specification (and no contents), just $ff and the type byte.
  - Any number of $ff bytes between segments is legal and must be skipped.

Segment types:
~~~~~~~~~~~~~~

   *TEM   = $01   usually causes a decoding error, may be ignored

        SOF0  = $c0   Start Of Frame (baseline JPEG), for details see below
        SOF1  = $c1   dito
        SOF2  = $c2   usually unsupported
        SOF3  = $c3   usually unsupported

        SOF5  = $c5   usually unsupported
        SOF6  = $c6   usually unsupported
        SOF7  = $c7   usually unsupported

        SOF9  = $c9   for arithmetic coding, usually unsupported
        SOF10 = $ca   usually unsupported
        SOF11 = $cb   usually unsupported

        SOF13 = $cd   usually unsupported
        SOF14 = $ce   usually unsupported
        SOF14 = $ce   usually unsupported
        SOF15 = $cf   usually unsupported

        DHT   = $c4   Define Huffman Table, for details see below
        JPG   = $c8   undefined/reserved (causes decoding error)
        DAC   = $cc   Define Arithmetic Table, usually unsupported

   *RST0  = $d0   RSTn are used for resync, may be ignored
   *RST1  = $d1
   *RST2  = $d2
   *RST3  = $d3
   *RST4  = $d4
   *RST5  = $d5
   *RST6  = $d6
   *RST7  = $d7

        SOI   = $d8   Start Of Image
        EOI   = $d9   End Of Image
        SOS   = $da   Start Of Scan, for details see below
        DQT   = $db   Define Quantization Table, for details see below
        DNL   = $dc   usually unsupported, ignore

        SOI   = $d8   Start Of Image
        EOI   = $d9   End Of Image
        SOS   = $da   Start Of Scan, for details see below
        DQT   = $db   Define Quantization Table, for details see below
        DNL   = $dc   usually unsupported, ignore
        DRI   = $dd   Define Restart Interval, for details see below
        DHP   = $de   ignore (skip)
        EXP   = $df   ignore (skip)

        APP0  = $e0   JFIF APP0 segment marker, for details see below
        APP15 = $ef   ignore

        JPG0  = $f0   ignore (skip)
        JPG13 = $fd   ignore (skip)
        COM   = $fe   Comment, for details see below

 All other segment types are reserved and should be ignored (skipped).

SOF0: Start Of Frame 0:
~~~~~~~~~~~~~~~~~~~~~~~

  - $ff, $c0 (SOF0)
  - length (high byte, low byte), 8+components*3
  - data precision (1 byte) in bits/sample, usually 8 (12 and 16 not
        supported by most software)
  - image height (2 bytes, Hi-Lo), must be >0 if DNL not supported
  - image width (2 bytes, Hi-Lo), must be >0 if DNL not supported
  - number of components (1 byte), usually 1 = grey scaled, 3 = color YCbCr
        or YIQ, 4 = color CMYK)
  - for each component: 3 bytes
         - component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q)
         - sampling factors (bit 0-3 vert., 4-7 hor.)
         - quantization table number

 Remarks:
  - JFIF uses either 1 component (Y, greyscaled) or 3 components (YCbCr,
        sometimes called YUV, colour).

APP0: JFIF segment marker:
~~~~~~~~~~~~~~~~~~~~~~~~~~

  - $ff, $e0 (APP0)
  - length (high byte, low byte), must be >= 16
  - 'JFIF'#0 ($4a, $46, $49, $46, $00), identifies JFIF
  - major revision number, should be 1 (otherwise error)
  - minor revision number, should be 0..2 (otherwise try to decode anyway)
  - units for x/y densities:
         0 = no units, x/y-density specify the aspect ratio instead
         1 = x/y-density are dots/inch
         2 = x/y-density are dots/cm
  - x-density (high byte, low byte), should be <> 0
  - y-density (high byte, low byte), should be <> 0
  - thumbnail width (1 byte)
  - thumbnail height (1 byte)
  - n bytes for thumbnail (RGB 24 bit), n = width*height*3

 Remarks:
  - If there's no 'JFIF'#0, or the length is < 16, then it is probably not
        a JFIF segment and should be ignored.
  - Normally units=0, x-dens=1, y-dens=1, meaning that the aspect ratio is
        1:1 (evenly scaled).
  - JFIF files including thumbnails are very rare, the thumbnail can usually
        be ignored.  If there's no thumbnail, then width=0 and height=0.
  - If the length doesn't match the thumbnail size, a warning may be
        printed, then continue decoding.

DRI: Define Restart Interval:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - $ff, $dd (DRI)
  - length (high byte, low byte), must be = 4
  - restart interval (high byte, low byte) in units of MCU blocks,
        meaning that every n MCU blocks a RSTn marker can be found.
        The first marker will be RST0, then RST1 etc, after RST7
        repeating from RST0.

DQT: Define Quantization Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - $ff, $db (DQT)
  - length (high byte, low byte)
  - QT information (1 byte):
         bit 0..3: number of QT (0..3, otherwise error)
         bit 4..7: precision of QT, 0 = 8 bit, otherwise 16 bit
  - n bytes QT, n = 64*(precision+1)

 Remarks:
  - A single DQT segment may contain multiple QTs, each with its own
        information byte.
  - For precision=1 (16 bit), the order is high-low for each of the 64 words.

DAC: Define Arithmetic Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Current software does not support arithmetic coding for legal reasons.
 JPEG files using arithmetic coding can not be processed.

DHT: Define Huffman Table:
~~~~~~~~~~~~~~~~~~~~~~~~~~

  - $ff, $c4 (DHT)
  - length (high byte, low byte)
  - HT information (1 byte):
         bit 0..3: number of HT (0..3, otherwise error)
         bit 4   : type of HT, 0 = DC table, 1 = AC table
         bit 5..7: not used, must be 0
  - 16 bytes: number of symbols with codes of length 1..16, the sum of these
        bytes is the total number of codes, which must be <= 256
  - n bytes: table containing the symbols in order of increasing code length
        (n = total number of codes)

 Remarks:
  - A single DHT segment may contain multiple HTs, each with its own
        information byte.

COM: Comment:
~~~~~~~~~~~~~

  - $ff, $fe (COM)
  - length (high byte, low byte) of the comment = L+2
  - The comment = a stream of bytes with the length = L

SOS: Start Of Scan:
~~~~~~~~~~~~~~~~~~~

  - $ff, $da (SOS)
  - length (high byte, low byte), must be 6+2*(number of components in scan)
  - number of components in scan (1 byte), must be >= 1 and <=4 (otherwise
        error), usually 1 or 3
  - for each component: 2 bytes
         - component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q), see SOF0
         - Huffman table to use:
        - bit 0..3: AC table (0..3)
        - bit 4..7: DC table (0..3)
  - 3 bytes to be ignored (???)

 Remarks:
  - The image data (scans) is immediately following the SOS segment.

VB3 source code: http://thelabwiz.home.mindspring.com/vbsource.html
VB6 source code: http://thelabwiz.home.mindspring.com/vb6source.html
VB6 - MySQL how to: http://thelabwiz.home.mindspring.com/mysql.html
Fix the obvious to reply by email.



Sat, 21 May 2005 09:35:03 GMT  
 old VB3 apps : info desperately needed, please help!
On Mon, 02 Dec 2002 20:35:03 -0500, the Wiz

Quote:

>My first guess is that the file is made up of a number of small images with some
>"position" information to allow building a "view" from many small images instead
>of one large one.  Considering the typical PC in the days of VB3, (640x480
>display, 800x600 was "high res") and "fast" 486 processors, this seems a
>reasonable assumption.  

>There are probably two ways of creating a new display program.

>1. Create a binary file reader to extract the images and their position info.
>Use a set of imageboxes to display the related images to make a larger image.

Hmmm,

that's correct: i found a java-prgram called jpg-extractor :
http://www.geocities.com/marcoschmidt.geo/jpeg-extractor.html

This resulted in the creation of 339 (!) small jpg's (max 32 k), but
when i try to open a jpg, irfanview says " Invalid  JPEG file
structure: SOS before SOF

Quote:
>2. Create the binary file reader to extract the images and save each one to a
>file, either with the coordinates in its name or with a generic name
>(group011image04.jpg) and a database that contains the file name and position
>data.  Load a set of imageboxes with related small images to get the larger
>image.

That would be nice, but with my programming experience  (Clipper) i'm
afraid that's no option for me....

Quote:
>In either case, you'll need the position data to know which image is next when
>scrolling (in any direction) and to determine when you're at the edge of the big
>image.  There may be "the next file is" type information in the image file, the
>program code, or an associated database or datafile (xxx.dat).

>This is an interesting project, but I have a paying client with deadlines...

Good for you, all i can offer you is external gratitude :-)

Thanks anyway!

Jan



Sun, 22 May 2005 18:48:46 GMT  
 old VB3 apps : info desperately needed, please help!


Quote:
>Good for you, all i can offer you is external gratitude :-)

should be 'eternal' of course .......

Jan



Sun, 22 May 2005 18:57:01 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Desperately need help printing vb3.0!!!!

2. VB3: DESPERATELY SEEKING SETUP info

3. Desperately need old file!

4. Data Environment help desperately needed please

5. Urgent help needed on an old VB4 app

6. Decompiling an old VB3 app

7. Extracting App Info From Win95 .LNK Files (Please Help)

8. PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP, PLEASE HELP,

9. NEED INFO ON OLD IBM DATATBASE PROGRAM: PERSONAL DECISION SERIES

10. old PC Basic bsave/bload info needed

11. Please Help Beginner - Jet Engine/Database Apps - VB3

12. Need help changing printer orientation from VB3 app under Win95

 

 
Powered by phpBB® Forum Software