How to make Opera 5.01 (or 4.02) usable
Update: 12.12.00 Opera v5.0
Update: 17.12.00 Opera v5.01
Last Update: 24.12.00 Email timezones/Hotlist column size
Opera 5.01 is out! As expected, the most blatant JavaScript bugs have been
fixed, and the email part also got better, but nevertheless some bugs and
inconveniences survived flawlessly. The remaining bugs in the email part
require patching at different offsets and/or with different bytes, which
are marked red. Also the new DLL can be downloaded.
Old 4.02 intro:
OK, so you just downloaded Opera for Windows 4.02 -- The Best Getting Even
Better --, and discovered that it really has got worse. The major
version change means they have completely redone it, and introduced LOTS of
new bugs on the way. Nonetheless, it is a great program, small, efficient,
lots of features you always wanted, and with the email and news integration,
it is a really good all-in-one browser.
Just that the email client is the source of the most horribly obvious bugs.
The minor version "02" suggests it isn't exactly a beta version anymore,
but some bugs are so overwhelmingly stupid one might think the programmers
are blind or constantly drunk.
Anyway, I sat down and did what I had to do. Apart from fixing real bugs,
there were things which I wanted Opera to do MY way, so there are two sections
below, the first deals with real bugfixes, the second with "adjustments".
The bytes which have to be changed in the appropriate DLL and the
corresponding offsets are given in hexadecimal. If you don't know how
to do byte patches (which by the way you SHOULD, there are quite enough
tutorials and tools out there, for example the
XVI32 Hex Editor),
the fixed and tweaked files are available for download at the bottom,
but of course just downloading and replacing them denies you the possibility
of choosing which bugfixes/tweaks to apply and which not.
Feel free to submit this site to any mailing lists/search engines/discussion
groups/FAQs, it is important to reach those desperate Opera users which would
otherwise turn their backs on this good program and return to Nutscrape or
Internet Exploiter.
If you have any suggestions concerning this site or discover/repair bugs which
aren't addressed here yet, email me.
Hope this helps,
IIXII
All byte changes apply to OMAIL32.DLL, whose size should be 262193
(294961) bytes, to be sure you have exactly the same version.
New: This page now also can be found at
Fravia's (Introduction/Tutti all'opera!).
Bugfixes:
Tweaks:
Downloads
Mail preferences bug
The newsgroups and mailing lists are being FLOODED with complaints about this
unbelievable failure of notice. I just had to include the disassembled source
(for those who are interested).
This is the guilty part of OMAIL32.DLL:
.text:1001D364 83 7D 0C 00 cmp [ebp+arg_4], 0
.text:1001D368 74 3A jz short use_default_val
.text:1001D36A 83 65 0C 00 and [ebp+arg_4], 0
.text:1001D36E 8D 4D 0C lea ecx, [ebp+arg_4]
.text:1001D371 6A 0A push 0Ah ;number base
.text:1001D373 51 push ecx ;pointer to result
.text:1001D374 50 push eax ;pointer to cfg value
.text:1001D375 E8 AA 9B 00 00 call _strtol ;convert string to int
.text:1001D37A 8B F8 mov edi, eax
....
.text:1001D38F 8B 45 08 mov eax, [ebp+result]
....
.text:1001D39D 89 38 mov [eax], edi
....
use_default_val:
It's part of a function which converts all preferences which are numbers
(also on/off preferences). As you can plainly see, there is an argument to
the function which tells it to always use the default value if it's zero.
I suppose the programmers put this in for testing, BUT FORGOT TO REMOVE IT
AGAIN, causing Opera to use DEFAULT VALUES every time you restarted it.
The astonishingly simple solution is to delete the jump.
OFFSET 1D368 74 3A -> 90 90
Column sort bug
In a mail folder window, you can click on the column headers of the mail
list and the mails are sorted accordingly. This setting is saved, on opening
a new mail folder window, the red arrow is where it should be, only the
sorting isn't performed! This bug is nearly as stupid as the preferences bug,
because on adding a new mail to the list, its expected position is
calculated, but not USED, it is always inserted at the end of the list.
This time a jump has to be inserted to FORCE resorting of the list.
If you apply the patch, the bug still occurs when unread mails are retrieved
from the server, they are always inserted at the beginning of the list.
Just change to a different folder and back to Inbox, then they are sorted.
OFFSET 15E29 183C3 74 2D -> EB 24
Word wrap bug
In the email preferences, you can specify the maximum characters per line,
longer lines are automatically wrapped. The mail input field is a RichEdit
control, which supports wrapping automatically, but the line width must
be set in twips, which are calculated using the current screen resolution
in dpi. On all three machines I tested this on, Windows tells Opera that the
resolution is 96 dpi, while the RichEdit control seems to need different
values according to the font size used. Can anyone give me a hint on this??
If you experience the same problem, that the lines are much longer than
specified, use the following patch. The value 7B is for composing with
Courier New 9, if you use any other font, you may have to experiment a little.
OFFSET 13FC0 75 03 6A 60 -> 90 90 6A 6C
1610A -> 90 90 6A 7B
Hangs while downloading mail
Many people also experienced this bug, but lots of others didn't.
Unfortunately I belonged to the latter, so I couldn't reproduce the bug at
first. Then I found an account per chance which showed the same error:
While retrieving mail, sometimes one or two mails were received correctly,
but then Opera invariably stopped in the middle of a mail. The mail transfer
could be aborted normally by clicking on the red x.
The error was hard to trace, but here it is:
When retrieving mail, the end of the mail body is marked by the server with
2E 0D 0A, a line containing only a single dot. Mails are always splitted
into blocks when being transmitted, and just a few mail servers send this
end marker in a seperate block, just containing these three bytes. But
Opera checks for 0A 2E 0D 0A, so the line with the single dot is only
noticed if it follows a line with other contents. If the end marker
is sent in a single block, Opera won't notice, and try to receive more mail
contents, which will never come. Once found, not too hard to patch:
OFFSET 1C8E4 04 -> 03
OFFSET 1C8F0 04 -> 03
OFFSET 1C8F2 DC -> DD
OFFSET 1C8F9 FC -> FD
Attachment bug
This bug was definitely the most devious, and the most difficult to fix,
hence it was the last one to be done. When a file is attached to an e-mail,
it is encoded as text, and the mail becomes "multipart", divided by
boundary strings. The mail program receiving the mail recognizes attachments
by the "content-type" setting, which is normally "text/plain", with
attachments "multipart/mixed". If the content type is set to text/plain,
but the mail contains multiple parts divided by boundary strings, the
person receiving the mail sees it as one part, and the attachments as
a garbled mess of text. This is exactly what Opera did: Always specifying the
content type as text/plain!! What made this one so very hard to trace was
the fact that Opera stores queued mails in the Outbox folder, the file
OUTBOX.MBS, which can be viewed with any text editor. In the Outbox folder,
the content-type and boundaries were specified correctly, and only just
before sending the data, the real mail header was constructed using the
wrong content-type!! As this code snippet shows, the content type is
hardcoded to text/plain:
.text:10006948 8B 03 mov eax, [ebx]
.text:1000694A C7 45 C4 50 24 03 10 mov [ebp+headerdata.contenttype], offset aTextPlain
.text:10006951 89 45 C8 mov [ebp+headerdata.priority], eax
.text:10006954 E8 6C 7C 00 00 call GetSubject
.text:10006959 89 45 C0 mov [ebp+headerdata.subject], eax
It was very hard to fix it, because this time, instead of patching some
bytes, there was actually code MISSING, which had to be inserted somewhere.
Fortunately (well, in this case) Windoze executables always contain plenty
of wasted empty space, which can be used for this purpose.
First, the code seen above has to be modified to use some other location,
where we put the correct content type, instead of aTextPlain, which is easy.
Second, we have to insert some code somewhere which stores the current
content type at this location, which is not so easy.
When loading a mail from a folder file, Opera uses a general parsing
function, whether the mail is to be displayed in the mail window or to be
sent. This parser examines the content type, but only to set a certain flag,
which is responsible for showing the little paper clip if the mail is to be
displayed in the mail list:
.text:1000DF0F 6A 0D push 0Dh
.text:1000DF11 68 B4 2B 03 10 push offset aContentType:
.text:1000DF16 57 push edi
.text:1000DF17 E8 D4 FD 01 00 call __strnicmp
.text:1000DF1C 83 C4 0C add esp, 0Ch
.text:1000DF1F 85 C0 test eax, eax
.text:1000DF21 75 10 jnz short NotContentType
.text:1000DF23 8D 47 0E lea eax, [edi+0Eh]
.text:1000DF26 8B CE mov ecx, esi
.text:1000DF28 50 push eax
.text:1000DF29 E8 BD 07 00 00 call SetContentFlag
Inserted code can be called by modifying calls to other functions. In the
snippet above, the call to SetContentFlag is replaced with a call to the
new function, which stores the content type (pointed to by eax) at the new
location chosen above, and then passes control to SetContentFlag.
So, first the location and the call have to be modified:
OFFSET 694D 50 24 -> 44 E3
OFFSET DF2A BD 07 00 -> 80 FE 01
Then the new function has to be inserted into wasted space, so all original
bytes are zero:
OFFSET 2DDAE E8 00 00 00 00 5A 81 C2 91 05 01 00 51 8A 08 88
0A 40 42 0A C9 75 F6 59 E9 20 09 FE FF
And last, the file sections have to be extended to mark the previously wasted
space as used:
OFFSET 1F0 AE -> CB
OFFSET 241 C3 -> C4
Language file bug
I suppose this affects all language files. The language files specify
replacement strings for menu and dialog items and popup tooltips. The
numbers are identical to the internal IDs. But the programmers assigned
some IDs *twice*, so the tooltips alternate between the right and the
wrong string. You have to comment out the duplicates, which isn't so bad
because those don't have to be translated anyway!!
Comment out the following lines in DE402.LNG
;10966="*.bmp"
;10969="http"
;10970="https"
;10972="ftp"
;10973="gopher"
;10974="wais"
;10949="Bitte Nickname eingeben"
;10945="Beschreibung"
;10955="Screenreader kompatible Men�s"
;10958="TN3270 Programm"
Mail list window size
A mail folder window is initially divided equally into the mail list
(upper part) and the mail view (lower part). My mail list is usually short,
while the mails themselves aren't. You can move the separator up, but
this setting isn't saved. The size is calculated as follows:
Percentage relative to whole window = (Dword at Offset 2000C)/655.36
Example: To make the mail list have 9 entries (28% of whole window), change
OFFSET 2000C 00 80 00 00 -> 00 48 00 00
Exchanging mailbox columns
The columns can be resized, but not exchanged. This is bad because I'm
used to having the subject appear before date and size. So what?
BTW: There are quite a lot of bytes to change. The first three exchange
the labels, the next three exchange the contents, and the rest are responsible
for making the sort criteria work again.
OFFSET 14A6B 16DBE CC -> CB
OFFSET 14A90 16DE3 CF -> CC
OFFSET 14ABF 16E12 CB -> CF (labels)
OFFSET 14C6E 170DA 1C -> 20
OFFSET 14C78 170E4 20 -> 24
OFFSET 14C8C 170F8 24 -> 1C (contents)
OFFSET 157E4 17D7C 0F 84 9E 00 00 00 49 74 51 49 0F 85 09 02 00 00
-> 74 0E 49 0F 84 9B 00 00 00 49 EB 4E 90 90 90 90
OFFSET 153BA & 153BD & 153DA & 153DD 1794A & 1794D & 1796A & 1796D 1C -> 20
OFFSET 15802 & 1581C 17D9A & 17DB4 06 -> 04
OFFSET 1584C & 15866 17DE4 & 17DFE 05 -> 06
OFFSET 15896 & 158B0 17E2E & 17E48 04 -> 05
OFFSET 157F7 17D8F AC -> A8
OFFSET 15841 17DD9 AA -> AC
OFFSET 1588B 17E23 A8 -> AA (sort on header click)
Default mailbox column size
This is more or less a bugfix, but closely related to the previous tweak,
thus listed here. You can resize the columns, the setting is saved in
COLUMNS.DAT, but not always properly loaded. So you can change the
default sizes, the proposed values are best for the exchanged columns.
OFFSET 14958 16CAB 14 -> 00 Column 1&2
OFFSET 149F1 16D44 14 -> 13 Column 3
OFFSET 14A3D 16D90 A0 Column 4 (lowres: 80)
OFFSET 14A7F 16DD2 78 00 -> 8B 01 Column 5 (lowres: 20 01)
OFFSET 14AAA 16DFD 32 -> 78 Column 6 (lowres: 74)
OFFSET 14ABC 16E0F -1 Column 7
For low resolutions or small screens it is useful to reduce the hotlist
width, but that causes the Unread and Total columns to disappear unless
their size is permanently adjusted as well (only for Opera 5.01):
OFFSET 19A5C 8B 4D F4 6A 14 89 48 2A -> 6A 1A 59 6A 35 89 48 4C Column 3&1
OFFSET 19A6C 7D 03 -> 90 90 ^^ ^^
OFFSET 19FD9 14 -> 1A Column 2
OFFSET 414D8 61 -> 00
OFFSET 414E6 65 -> 00
Timezone correction
This omission really got annoying as I subscribed to the Opera Users Mailing
List. I received dozens of mails every day from all corners of the world,
and the mail folder always displayed the corresponding local time.
Sorting that folder by Date totally screwed up the Request/Replies order,
so I wanted the time to be converted to my local time. Like with the
attachment bug, code had to be inserted (see detailed
explanation of how to do that there). If you think the inserted code
is quite long, blame the snooty Americans. In their well-known ignorance
of everything outside their borders, they assume everyone knows their
hilarious timezones like "Mountain Daylight Time", so services like AOL
don't append "-0600 (MDT)", as every sane mail client would do, but just
"MDT". Thus a conversion table for thirteen timezone abbreviations had to
be included, providing for more than half the code.
OFFSET 1F8 1D -> AB (increase code section)
OFFSET 3598 F1 58 -> 25 70 (gmtime -> localtime)
OFFSET FA7A 2D A2 01 -> 9F 26 02 (mktime -> new inserted function)
OFFSET 3211D 5F 83 C6 03 0F B7 46 01 66 2D 30 30 86 E0 D5 0A
80 3E 2D 74 25 F7 D8 80 3E 2B 74 1E 8B 56 FF 8D
B7 F9 26 02 00 6A 0D 59 8B 06 B0 20 3B C2 74 07
83 C6 04 E2 F3 EB 1C 0F B6 06 01 45 D4 E8 8F A1
FF FF 8B 87 D2 96 02 00 99 B9 10 0E 00 00 F7 F9
29 45 D4 E8 36 7B FF FF FF E7 00 47 4D 54 03 41
44 54 04 41 53 54 04 45 44 54 05 45 53 54 05 43
44 54 06 43 53 54 06 4D 44 54 07 4D 53 54 07 50
44 54 08 50 53 54 09 48 44 54 0A 48 53 54
Incomplete german language file
The translator forgot several items.
Add the following lines in DE402.LNG in the appropriate sections:
[Translation]:
10920="Lesezeichen f�r aktuelle Seite erstellen"
10921="Lesezeichenordner erstellen"
10922="Lesezeichenbefehle"
10925="Adresse erstellen"
10926="Adressordner erstellen"
10927="Adressbefehle"
14494="Wollen Sie wirklich:\r\n\r\n Alle Fenster schlie�en\r\n\r\n
Alle nicht-dauerhaften Cookies l�schen\r\n\r\n Alle Passw�rter
l�schen\r\n\r\n Alle Dokumente aus dem Cache entfernen, die mit
einem Passwort oder Verschl�sselung geladen wurden\r\n\r\n\r\nSind
sie sicher?"
14495="Private Daten l�schen"
[Menu]:
14493="Private &Daten l�schen"
10059="�ffne &WWW-Adresse (URL)\tF2"
10087="Zu &Lezeichen hinzuf�gen\tCtrl+T"
12035="&Verkn�pftes Fenster �ffnen"
10523="Fenstereinstellungen speichern"
DO NOT link to these downloads directly, FortuneCity
doesn't like externally linked files. Link to this page you are currently
viewing instead. When trying to download the following with Opera, make
sure your "File/Preferences/Privacy/Enable referrer logging" setting is on,
else FortuneCity won't give you the files.
Download patched OMAIL32.DLL (145920 bytes) for v4.02
Download patched OMAIL32.DLL (137769 bytes) for v5.0
Download patched OMAIL32.DLL (138031 bytes) for v5.01
Download patched OMAIL32.DLL 800x600 low resolution version (138043 bytes) for v5.01
Warning: The DLL contains all bugfixes and tweaks mentioned above. It is
compressed with ASpack, so it makes Opera even smaller on your hard disk
because it is decompressed to memory every time you run Opera, and it loads
faster, because decompression time is less than the time saved by shorter
disk access due to smaller size. Still check the size of the file you replace.
Download ZIPed german language file DE402.LNG (28480 bytes)
Made with Norton Editor 2.0 for DOS [und vieeel Zeit]