How to have the minimum size possible Chromium Embedded Framework dlls

Gad D Lord picture Gad D Lord · Nov 22, 2011 · Viewed 11.6k times · Source

Chromium Embedded Framework (http://code.google.com/p/delphichromiumembedded/) is good. I use it to display static HTML, JS and CSS generated from Delphi code only.

But I find it too big.

I need:

  • I need HTML support
  • I need JavaScript support.
  • I need CSS support.
  • I need Unicode support.
  • I need OnNavigate event.

Don't need:

  • I don't need D3D, GDI+, GLES support.
  • I don't need ability to load a web page. LoadString is enough for me.
  • I don't need Locales
  • I don't need Caching
  • I don't need Developer Tools

How I can achieve to have the needed features by having the minimum possible deployment package?

Currently CEF has 40 MB of dlls.

Answer

Arnaud Bouchez picture Arnaud Bouchez · Nov 22, 2011

About reducing the CEF library size itself, it will need a full rebuilt, and some debugging phase. A lot of time spent, perhaps not worth it - 40 MB is small, according to today's computer power and network bandwidth. I would rather rely on the "official" release of CEF to stay tuned with the latest versions of the browser.

If your issue is about deployment package size and single executable/no install feature, you may consider embedd the dlls inside the exe.

The trick I've used is that the .dll files are stored as zip inside the main .exe, then uncompressed on a private temporary folder on the hard drive (you may want to use the same folder, but it won't work in C:\Program Files due to the Vista/Seven UAC, and your user may wonder where all those files comes frome - that is the reason why I use a private folder).

From the user point of view, there is just one executable file to run. All .dll files are compressed within, and you can also add some non-binary resources to the files (which is not possible with exe/dll compactors). An hidden folder is created and used to load the libraries (which must be loaded with LoadLibrary(), not statically linked), and decompression will be done only once (therefore it will be faster than using an exe/dll compressor).

I've used it for instance to embedded the hunspell.dll library and the English dictionary to our SynProject tool. Code looks like the following:

constructor THunSpell.Create(DictionaryName: string='');
var Temp, HunSpell, Aff, Dic: TFileName;
    i: integer;
begin
  if DictionaryName='' then
    DictionaryName := 'en_US';
  Temp := GetSynopseCommonAppDataPath;
  HunSpell := Temp+'hunspell.dll';
  with TZipRead.Create(HInstance,'Zip','ZIP') do
  try
    Aff := DictionaryName+'.aff';
    if not FileExists(Temp+Aff) then
      StringToFile(Temp+Aff,UnZip(NameToIndex(Aff)));
    Dic := DictionaryName+'.dic';
    if not FileExists(Temp+Dic) then
      StringToFile(Temp+Dic,UnZip(NameToIndex(Dic)));
    if not FileExists(HunSpell) then
      StringToFile(HunSpell,UnZip(NameToIndex('hunspell.dll')));
  finally
    Free;
  end;
  fHunLib := SafeLoadLibrary(HunSpell);
  if fHunLib=0 then
    exit;
  if not LoadEntryPoints then begin
    FreeLibrary(fHunLib);
    fHunLib := 0;
    exit;
  end;
  fDictionaryName := DictionaryName;
  fHunHandle := Hunspell_create(pointer(Temp+Aff),pointer(Temp+Dic));
  if fHunHandle=nil then
    exit;
   (....)
end;

See this link about details and source code.

You may consider using some low-level hack like BTMemoryModule, but you won't have any possible compression.