How to make Opera 5.0 (or 4.02) usable
Update: 29.11.00 (4.02 attachment bug FIXED!)
Last Update: 12.12.00 Opera v5.0 demands patching
Opera 5.0 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 181E3 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
160F4 -> 90 90 6A 7B
Javascript variable error
There is a very annoying Javascript interpretor bug in the allocation of
global variables. If a function is called across document boundaries, e.g.
a frame child calls a function of the parent document, the latter function
cannot allocate ANY global variable!! I haven't been able to fix this up to
now.
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 16BED CC -> CB
OFFSET 14A90 16C12 CF -> CC
OFFSET 14ABF 16C41 CB -> CF (labels)
OFFSET 14C6E 16F09 1C -> 20
OFFSET 14C78 16F13 20 -> 24
OFFSET 14C8C 16F27 24 -> 1C (contents)
OFFSET 157E4 17B9C 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 1776A & 1776D & 1778A & 1778D 1C -> 20
OFFSET 15802 & 1581C 17BBA & 17BD4 06 -> 04
OFFSET 1584C & 15866 17C04 & 17C1E 05 -> 06
OFFSET 15896 & 158B0 17C4E & 17C68 04 -> 05
OFFSET 157F7 AC -> A8
17BAF A8 -> A4
OFFSET 15841 AA -> AC
17BF9 A6 -> A8
OFFSET 1588B A8 -> AA (sort on header click)
17C43 A4 -> A6
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 values given correspond to the exchanged columns.
OFFSET 14958 16ADA 14 -> 00 Column 1&2
OFFSET 149F1 16B73 14 -> 13 Column 3
OFFSET 14A3D 16BBF A0 Column 4
OFFSET 14A7F 16C01 78 00 -> 8B 01 Column 5
OFFSET 14AAA 16C2C 32 -> 78 Column 6
OFFSET 14ABC 16C3E -1 Column 7
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, or FortuneCity
will remove public access to them because they don't like externally linked
files. Link to this page instead.
Download patched OMAIL32.DLL (archive 123 kB) for v4.02
Download patched OMAIL32.DLL (archive 135 kB) for v5.0
Warning: The DLL contains all bugfixes and tweaks mentioned above. It is
compressed with ASpack, so it is downloaded faster and makes Opera even
smaller on your hard disk. Still check the size of the file you replace.
Download ZIPed german language file DE402.LNG (archive 28 kB)
Made with Norton Editor 2.0 for DOS [und vieeel Zeit]