SmartPDF (aka SumatraPDF) in rosapps, linking problems

[Klemens Friedl]

SumatraPDF is a lightweight Win32 pdf viewer app
http://blog.kowalczyk.info/software/sumatrapdf/
http://code.google.com/p/sumatrapdf/

The name "sumatra" sounds weird (for an app), so I renamed the
directory and the output exe file to "SmartPDF" (based on suggestions
from #reactos).

SumatraPDF comes with VS 2k5 project files.
I have fixed various compile issues so that libjpeg, poppler,
fitz/mupdf and sumatra app itself compile without errors in mingw
(RosBE 0.3.7.2 Win32).
All code changes can be found by grep/search for "@note:", I added a
comment to each changed code line.

The remaining problem is the linking issue. Currently it does NOT link
correctly.

Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be
related to the issue:
"it [sumatrapdf] imports a function from winspool.drv by number, when
you add that number to winspool.def, it starts"


Please have a look at it, fixes are appreciated :)


Klemens

[Timo Kreuzer]

I could resolve most of the linking errors by reordering the libs in the 
rbuild file.
Yes, it does matter ;-)
There are still 4 unresolved references left:
`LaunchBrowser(char const*)'
`_wstr_dup'
`_WinMain@16'
`_FT_Get_X11_Font_Format'

btw: is 'Kopie von SumatraPDF.cpp' still needed?

Timo

Klemens Friedl wrote:
>   SumatraPDF is a lightweight Win32 pdf viewer app
>  http://blog.kowalczyk.info/software/sumatrapdf/
>  http://code.google.com/p/sumatrapdf/
>
>  The name "sumatra" sounds weird (for an app), so I renamed the
>  directory and the output exe file to "SmartPDF" (based on suggestions
>  from #reactos).
>
>  SumatraPDF comes with VS 2k5 project files.
>  I have fixed various compile issues so that libjpeg, poppler,
>  fitz/mupdf and sumatra app itself compile without errors in mingw
>  (RosBE 0.3.7.2 Win32).
>  All code changes can be found by grep/search for "@note:", I added a
>  comment to each changed code line.
>
>  The remaining problem is the linking issue. Currently it does NOT link
>  correctly.
>
>  Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be
>  related to the issue:
>  "it [sumatrapdf] imports a function from winspool.drv by number, when
>  you add that number to winspool.def, it starts"
>
>
>  Please have a look at it, fixes are appreciated :)
>
>
>  Klemens
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Klemens Friedl]

2007/9/30, Timo Kreuzer <timo.kreuzer(a)web.de>de>:
>   I could resolve most of the linking errors by
> reordering the libs in the
>  rbuild file.
>  Yes, it does matter ;-) 
okay, I understand.

>   There are still 4 unresolved references left:
>  `LaunchBrowser(char const*)' 
... this one is a minor feature (launch a browser
after clicking on a
link), and I have commented it out for the meanwhile

>   `_wstr_dup'
>  `_WinMain@16' 
hm, don't know why


>   `_FT_Get_X11_Font_Format' 
... is related to
freetype, our freetype has only
"FT_Get_X11_Font_Format" but none with leading underscore (ftxf86.c
and ftxf86.h of freetype).


>   btw: is 'Kopie von SumatraPDF.cpp' still
> needed? 
no, I deleted it plus some other unnecessary files


Klemens

[Timo Kreuzer]

Klemens Friedl schrieb:
> >  
> > `_FT_Get_X11_Font_Format'
> >       
>  ... is related to freetype, our freetype has only
>  "FT_Get_X11_Font_Format" but none with leading underscore (ftxf86.c
>  and ftxf86.h of freetype).
>     
The underscore is always added. The problem is that our freetype.dll 
doesn't export FT_Get_X11_Font_Format.
But there's another problem: our freetype dll is a kernel mode dll 
linking to ntoskrnl.exe, so even if you could link the app, it wouldn't 
work. So you would first need to compile freetype as a static lib.

Timo

[Klemens Friedl]

I have fixed all remaining linking issues EXCEPT one, the '_WinMain@16' issue.


[LD]       output-i386\modules\rosapps\smartpdf\smartpdf.exe
obj-i386\lib\3rdparty\mingw\mingw_main.a(main.o): In function `main':
trunk/reactos/lib/3rdparty/mingw/main.c:73: undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
mingw32-make: *** [output-i386\modules\rosapps\smartpdf\smartpdf.exe] Error 1


The main function of SmartPDF/SumatraPDF:

int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow) { ... }

... I have checked some other ros GUI apps like solitaire, which have
the save definition, except "WinAPI" instead of "APIENTRY". Although
using "WinAPI" there doesn't solve the issue.

Fixes for this mingw linking issue are appreciated.


Klemens

[Ged]

Klemens Friedl wrote:
>   SumatraPDF is a lightweight Win32 pdf viewer app
>  http://blog.kowalczyk.info/software/sumatrapdf/
>  http://code.google.com/p/sumatrapdf/
>     
But why this been imported into our repositry?
What interest do we have in some 3rd party pdf reader?

[Timo Kreuzer]

It might help get it work ;-)

Ged schrieb:
>   Klemens Friedl wrote:
>    
> >   SumatraPDF is a lightweight Win32 pdf viewer app
> >  http://blog.kowalczyk.info/software/sumatrapdf/
> >  http://code.google.com/p/sumatrapdf/
> >    
> >       
>  But why this been imported into our repositry?
>  What interest do we have in some 3rd party pdf reader?
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Ged]

Timo Kreuzer wrote:
>   It might help get it work ;-)
>  

Maybe we should import every available win32 application into our 
repository then, in the hope of getting everything to work ;)

[Klemens Friedl]

>   But why this been imported into our repositry?
>  What interest do we have in some 3rd party pdf reader? 
The idea was to have some lightweight apps similar to the vision of
Win95. All recent operating system have a PDF viewer as it's (beside
DOC) the number one document format. My plan was to remove one of the
pdf engines and add office format support (ole2, using libgsf
library), so we would have a very lightweight document viewer app. An
shell extention could then add preview & metadata of documents to
explorer/shell.

I have also plans for a indexing service that provides system wide
search and an interface to be compatible with MS iFilter, WordBreaker,
etc.
The current plan for such an indexing service is to use SQLite3 and
CLucene. SQLite3 is a public domain very lightweight SQL engine that
is used in a lot of software (I bet it is already in use on all of
your computers and your cellphones, mp3 players, etc.). CLucene is a
C++ port of the famous Java fulltext search engine. SQLite3 got a
fulltext engine plugin itself, thanks to a google dev, called "FTS".
It's currently limited but looks promising too.
Of course, MS neither use SQLite nor CLucene for their indexer, but
use their own database engine, based on SQL products that they have
bought a long time ago.
Writing a new database with fulltext support from scratch is not
feasonable, and giving the fact that all recent software switched to
SQLite (several new Microsoft software and games, google gears, new
GMail, Google Reader, Google Desktop, Adobe Lightroom, several Apple
software (coredata OS core lib, Spotlight search engine, iPhoto,
etc.), I think it's ok to choose it.

An iFilter dll would use the pdf engine to extract the text and the metadata.
I have planned to add some lightweight Win32 apps (E-Mail client, IRC
client, PDF/Office-format viewer).
As a PDF iFilter would be a needed anyway (at least in my opinion), so
poppler is required too, and then a lightweight PDF viewer is just a
matter of a few more source files. (currently, it consists of two pdf
engines, one needs to be removed, one is optional anyway).

The overall goal is that is to have a handful of basic apps similar to
Win95 (paint, email, etc.) and a system wide search that indexes
several important formats (plugin based, with iFilter interface to be
compatible with MS search products).


If a pdf vieweror a document viewer in general don't fit in "rosapps",
then move it somewhere else, delete it or revert the commit(s).

If someone thinks that a indexer is not needed, and Google Desktop or
any other third party desktop search engine is enough. Then you have
probably never used a so called "desktop search". Please try out one,
and you will see none of them even comes close to Apple Spotlight on
MacOS X 10.4 (Tiger), and remember even Spotlight isn't that great
(search results, boolean search), Google WebSearch is still a lot
faster and delivers better search results.
I am planning on the indexer for abouzt 1 1/2 years and the current
status is that almost all third party libs compile with the reactos
build environment in my local tree. Additionally, several test apps
already work fine. One major issue is how to write the IDL for the
iFilter interface. Another one is how to parse the search-input and
send it to the right search engine and combine the results
efficiently. But that's something for another ML-thread.


Klemens

[Wesley Parish]

On Monday 01 October 2007 06:30, Klemens Friedl wrote:
> >   But why this
> > been imported into our repositry?
> >  What interest do we have in some 3rd party pdf reader? 
>  The idea was to have some lightweight apps similar to the vision of
>  Win95. All recent operating system have a PDF viewer as it's (beside
>  DOC) the number one document format. My plan was to remove one of the
>  pdf engines and add office format support (ole2, using libgsf
>  library), so we would have a very lightweight document viewer app. An
>  shell extention could then add preview & metadata of documents to
>  explorer/shell.
>
>  I have also plans for a indexing service that provides system wide
>  search and an interface to be compatible with MS iFilter, WordBreaker,
>  etc.
>  The current plan for such an indexing service is to use SQLite3 and
>  CLucene. SQLite3 is a public domain very lightweight SQL engine that
>  is used in a lot of software (I bet it is already in use on all of
>  your computers and your cellphones, mp3 players, etc.). CLucene is a
>  C++ port of the famous Java fulltext search engine. SQLite3 got a
>  fulltext engine plugin itself, thanks to a google dev, called "FTS".
>  It's currently limited but looks promising too.
>  Of course, MS neither use SQLite nor CLucene for their indexer, but
>  use their own database engine, based on SQL products that they have
>  bought a long time ago.
>  Writing a new database with fulltext support from scratch is not
>  feasonable, and giving the fact that all recent software switched to
>  SQLite (several new Microsoft software and games, google gears, new
>  GMail, Google Reader, Google Desktop, Adobe Lightroom, several Apple
>  software (coredata OS core lib, Spotlight search engine, iPhoto,
>  etc.), I think it's ok to choose it. 
This triggered a memory: Managing Gigabytes (text searcher and indexer): 
http://www.ncsi.iisc.ernet.in/raja/netlis/wise/mg/mainmg.html
http://www.cs.mu.oz.au/mg/
http://www.cs.mu.oz.au/mg/preface.html

And a text search engine (not an indexer):
http://www.cs.mu.oz.au/~oldk/seft/

You might like to take a look at them.

Wesley Parish
<snip>
>  
>  If someone thinks that a indexer is not needed, and Google Desktop or
>  any other third party desktop search engine is enough. Then you have
>  probably never used a so called "desktop search". Please try out one,
>  and you will see none of them even comes close to Apple Spotlight on
>  MacOS X 10.4 (Tiger), and remember even Spotlight isn't that great
>  (search results, boolean search), Google WebSearch is still a lot
>  faster and delivers better search results.
>  I am planning on the indexer for abouzt 1 1/2 years and the current
>  status is that almost all third party libs compile with the reactos
>  build environment in my local tree. Additionally, several test apps
>  already work fine. One major issue is how to write the IDL for the
>  iFilter interface. Another one is how to parse the search-input and
>  send it to the right search engine and combine the results
>  efficiently. But that's something for another ML-thread.
>
>
>  Klemens
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves.  Things which are 
impossible are equal to each other.  Guerrilla 
warfare means up to their monkey tricks. 
Extracts from "Schoolboy Howlers" - the collective wisdom 
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.