--------- 1.symptoms -----------------------------
Have you download a rtf_file,
(ex. rabbit.rtf in this folder),
which include an emf_image(Enhanced windows
Metafile Format, vector graph, use to reduce file size),
but when you open this rtf with wordPad,
actually you can NOT see that image?
That's the bug in m$' richedit dll.
--------- 2.affected part in c code --------------
The source code of this bug,
in CRTFRead::StaticObjectReadFromEditStream()
{
IOleCache::SetData(&formatetc, &stgmedium, 1);
}
Case the image is emf, we must do:
2.1.set formatetc.cfFormat = CF_METAFILEPICT;//3
2.2.set formatetc.tymed = TYMED_MFPICT;//0x20
2.3.set stgmedium.hGlobal = SetEnhMetaFileBits()
And before those setting, we must call
OleCreateDefaultHandler(CLSID_Picture_EnhMetafile)
to notify the ole system.
But m$ do NOTHING. That's why the image is disapper.
And before the above function be called,
in another function TokenFindKeyword(),
m$ ignore keywords"\emfbip" deliberately.
So the parameter ObjectType hadn't be passed to function
StaticObjectReadFromEditStream(). Of course, even it is passed,
the switch(ObjectType) in latter function is:
case ROT_BITMAP: ...CreateBitmap() ...
case ROT_METAFILE: ...SetMetaFileBitsEx()...
case ROT_DIB: ...
case ROT_ENHMETAFILE(no this case!!)
So that's why we say "m$ do NOTHING".
And m$ make this bug of wordPad in win98,win2k,winXp,...
but NEVER in any version of m$ office.
WordPad is gratis version, but word is fee-based version.
--------- 3.solution -----------------------------
In summary, after we notice this bug, we can:
3.1)install m$ office, that means $.
3.2)install openOffice or libreOffice,
that means netWork & disc_space.
3.3)DIY. Modify the binary code in dll.
3.2's disc_space, is 0.6G bytes for openOffice
and 1G bytes for libreOffice.
3.3 is less than 200 bytes.
User even can manually modify them byte by byte.
Oh...no, just a joke!
Because we have modify the dll byte by byte,
and compare the new_dll with its backup_file
by file_compare command in binary mode:
"fc /b xxx.dll.bak xxx.dll > fc.txt".
So user can differ from this result(fc.txt),
just input "difc.exe fc.txt" in console,
to make a new_dll as well.
That means we should:
3.3.1: ready for 3 file.
3.3.1.1: copy xxx.dll to another folder.
(For win98,win2k, xxx.dll = richEd20.dll
For winXp,win7, xxx.dll = msftEdit.dll)
3.3.1.2: Download fc.txt by xxx.dll's version,
into the above folder.
3.3.1.3: Copy wordPad.exe into the above folder too.
3.3.2: reName xxx.dll to xxx.dll.bak, as backup_file.
3.3.3: input "difc.exe fc.txt" in console.
Ok, after we click wordPad.exe in the above folder,
we can use it to open any rtf which including emf_image
(ex. rabbit.rtf in this folder) now.
--------- 4.FAQ ----------------------------------
Q 4.1: How many bytes we modify?
A 4.1: Less than 200 bytes. We can see that in fc.txt,
each line describe a byte's original & modify,
and give out its offset in file.
And there are less than 200 lines in fc.txt.
Q 4.2: How to prove "we just modify less than 200 bytes"?
A 4.2: In the above folder,
we can compare the new_dll with its backup_file
by file_compare command in binary mode:
"fc /b xxx.dll.bak xxx.dll > fc.txt" in console.
(repeat: For win98,win2k, xxx.dll = richEd20.dll
For winXp,win7, xxx.dll = msftEdit.dll)
Then we can see a same fc.txt including less than 200 lines.
Q 4.3: Why modify those bytes?
A 4.3: To set CLSID, formatetc.cfFormat and ...
formatetc.tymed, see also 2.1~2.3.
And to set stgmedium.hGlobal,
we replace Escape() to SetEnhMetaFileBits().
About the detail, see also in readme.txt
in folder corresponding the version of xxx.dll.
--------- 5.after word ---------------------------
The bug appear in win98,win2k,winXp,win7....
And this bug appear in winCE too. But noway for solution,
because in winCE's coreDll, all the api about "meta",
are only 4 funtions: CloseEnhMetaFile, CreateEnhMetaFileW,
DeleteEnhMetaFile, PlayEnhMetaFile.
By https://learn.microsoft.com/en-us/previous-versions/windows/embedded/ms927613(v=msdn.10)
GDI Functions (Windows CE 5.0) without any "meta" functions.
Start with win10 v.1903, m$ block the embedded content
in wordPad, show messageBox(security warning):
"some content of this document has been blocked,
because the source of this document might not be trusted.
If you trust the source of this document,
click Unblock to show all content."
Therefore, if we click "unblock", then we can see
the emf_image. Is it a good news or bad news?
And after windows 11 24h2, m$ delete wordPad.
Bad news.
