Experiences with UdiWWW

Introduction to these notes

This is a historical document only. This note was partially updated in response to the release of version 1.2.000, in 1996. It appears that the author "froze" the project soon afterwards, and after some time, his personal web pages disappeared from the U.Ulm server. Copies can however be located in other web archives.

Version 1.2.000

Version 1.2.000 is out, and supports MATH. Excellent results for the most part, although math sections included in running text do not seem to share the same baseline, which gives a somewhat ragged effect.

I'm still not sure what's meant to be the optimum way to use the history window. Intuitively, I would have expected a double-click on the desired item to go there (it doesn't). The next most intuitive thing to do would be a right-click on the desired item (no good - it opens a little menu, but the target is the item that's currently shown framed, rather than the one on which you clicked).

In the end, the shortest way to get to a desired item on the history window seems to be a left click on the desired item, then a right click, and then left click on the first entry in the resulting little menu.

All stuff from here is out of date

A random collection of remarks describing experiences I had with the UdiWWW browser. This was last updated just after I started using 1.0.009. Sorry, haven't had time to update it with more recent experiences; it's a nice browser for the most part, but with some irritating bugs and features, and even under Win'95 it's not crash-free. For a one-man job, though, I have to take my hat off to the author.

Neither UdiWWW nor Arena implement the full range of HTML3 constructs yet, nor even all of the ones that have been reasonably stable in the spec for some time. Each implements the authors' choice, according to their own priorities. As the arena distribution notes put it: "please set your expectations accordingly".

However, I think it is fair to say that UdiWWW has a reasonable range of user facilities (history stack, bookmarks etc.), and I am quite happy to use it as an everyday browser, whereas arena's user facilities are exceedingly primitive and mean that I would not consider arena as my everyday browser, I only use it when I want to take advantage of its specific features. Arena does not even support forms yet, as far as I know, whereas I have not found anything in HTML2 that UdiWWW does not support acceptably.

Of course, arena is a unix-based browser - I use it under Ultrix and/or DEC OSF/1 - whereas UdiWWW is MS-Windows based - I use it successfully under Win'95 beta, although some contributors to the WWW usenet groups suggest that it may be less successful in its 16-bit version under earlier Windows versions.

Distribution

I got it from http://www.uni-ulm.de/%7Erichter/ by following the obvious link. [But it's not there any more, so I've de-activated the link to it.]

Installation and startup

Version 1.0.008 of UdiWWW was straightforward to unpack (self expanding archive), and gave startup problems in only one area, which I describe next. The problems encountered with some earlier versions, in which it seemed to be looking for some files (caches, bookmark) that it had not yet created, and failing to start because they weren't there, seem to have been corrected now.

The problem was with CTL3D32.DLL, which UdiWWW insisted that it needs. But I did not have a Win'95 compatible CTL3D32.DLL, and did not know where to find one (the ones that I found on the net were either Win 3.1 or Win/NT). However, Bernd now has a suitable version, CTL3D32W95.DLL, on his server. This file needs to be copied (or moved) into the \WINDOWS\SYSTEM directory of your Win'95 system, and renamed to CTL3D32.DLL - note that you should not rename any other copy of this file to be CTL32D32.DLL, e.g the one that you fetched into your UdiWWW folder, or else you will get a startup nastygram saying that the component has been incorrectly installed.

I had a problem with the English version of version 1.0.009. It started up OK, but when I chose the Setup menu, Win'95 terminated it with an "illegal operation" nastygram. Bernd gave me the following workaround (this procedure is also described on his distribution page, for situations where you have problems with the DLL, but I would have no idea how to identify that the problem was with the DLL ;-)

Start the UdiWWW program with the -r option, e.g D:\Udiwww\Udiwww32.exe -r .
This causes the program to startup in German using its built in resources. Now use the menu Optionen/ Einstellungen/ Sonstiges and specify the resource file containing the English, e.g Udiwre01.dll.
On exit from the menu it will tell you to restart the program. Exit from the program and start up again without the -r option.

After this, the program can be started up OK and comes up in English. I don't understand the details of the problem but this workaround did the trick.

I also saw some strange formatting in 1.0.009. Bernd's answer was that the use of the formatting parameters has changed in 1.0.009 and it's necessary to use different defaults. The easiest way is to delete the program's INI file, in my case UDIWWW32.INI, before starting the program. Then you have to re-instate any settings that you needed from before (I guess careful editing of the INI file might do it, but...).

Supported protocols

UdiWWW only supports http protocol at the moment. It therefore cannot directly open URLs of type ftp, gopher, etc. This is no problem if you have access to a cache proxy server, as we have. We merely pull down UdiWWW's configuration menu for proxies, and insert the domain name and port number of the proxy server into the relevant fields for ftp and gopher. UdiWWW then uses a http protocol connection to the proxy server for making any ftp or gopher connections.

I have no solution to "news:" protocol. But I prefer to use a proper usenet client anyway, rather than a WWW browser.

Supported content-types

Starting version 1.0.009, UdiWWW displays plain text automatically.

Paragraph formats

See the note above regarding the use of the formatting parameter defaults in 1.0.009.

Options/Settings/Styles panel. Select "Standard" format and edit the item "First" to a non-zero number, say 20. Press "Test" and you will see the effect in the little window. Click on "OK" and this becomes your chosen setting. N.B At 1.0.008, changes only take effect if you press Test. Starting 1.0.009, you can click immediately on OK, if you don't want to test.

You could also try the effect of "Left" to 40 and "First" to -20 to get a hanging indented paragraph. Etc. The same controls are available on all other formats (unordered list, definition list, etc.) so you could play around with those also; probably not a good idea to do this with preformatted style though!

Copy/Paste

At 1.0.008, the only way to Copy or Paste between the URL window and clipboard was to use cursor placement followed by shortcuts, e.g Ctrl/C (copy highlighted area from URL window) and Shift/Ins (paste into URL window). The Edit/Copy menu item only copied the whole source document into the clipboard, no matter where the cursor was located.

With 1.0.009, the Edit menu now has Copy-URL and Paste-URL items. Edit/Copy still works on the whole source document: Bernd promises selections for later.

Bugs, infelicities, features...

I think the only way to update the browser display when the document has been updated on the server, is first to use the "View/Reopen" menu item, and then to use the "View/Refresh" item or the corresponding toolbar button (6th from the left). Is this true, and if so, why can there not be just one button action to include both? I understand that it may be useful to "Refresh" without reloading, but I don't understand how it could ever be useful to "Reopen" without "Refresh"ing.
Sometimes the browser fails to display the whole text: parts of it come out blank. In-line images are sometimes affected this way too. Sometimes this can be corrected by scrolling it off the visible window and then back on again; other times it can only be corrected by the View/Refresh menu item, or the corresponding toolbar button.
The problem was, that the text was formatted right, but not always displayed. You could see this, if you move another window over UdiWWWs client area, to force a Update on UdiWWW without parsing the HTML again, and the text is visible.
It should be better now, also on a page which contains forms. On this pages there were sometimes only the FORM elements (input, radio,.. ) visible.
1.0.009 certainly seems to be better in this respect.
Use of the "Back" button sometimes goes to a page that is not the one that was visited last. I think this is in situations where the page in question should appear more than once in the history stack, but it looks to be as if he only keeps it once, and gets confused about the path which the user had been following. I hope this is a mistake rather than a deliberate intention.
The Author of UdiWWW was also wondering of the strange History, but he could not find the mistake yet (no intention).
At 1.0.008, the "Navigate/History" display appeared in a tiny window, and had to be dragged out to a reasonable size for use. If the sub-window was then dismissed using its "Close" button, and later re-opened, its size had reverted to the tiny window. This does not happen if the Windows'95 close button [x] was used instead. The problem is corrected in 1.0.009.
At 1.0.008, if a document starts with normal text (i.e without a header), the second word of the text overwrites the first word. Fixed in 1.0.009. However, I see that in 1.0.009 there seem to be some unexpected indents occurring immediately after the end of a header, a UL, etc. if followed by text that is not enclosed in a container (such as <p>). Although it is wrong in strict HTML to have text not enclosed in a container, it's rare for authors to actually write "strict" HTML, and I've never seen anyone actually advocating it for "manually" composed HTML.
UdiWWW does not honour Status 204 from the server.
This is true. UdiWWW honours only the 302,301 Status, where a document has moved, or 401 because of Authentication.
There were some curiosities in the parsing of ALT texts in IMGs, when these texts contain HTML-significant characters. Remark: most browsers have anomalies in this area, so this is not specifically a fault of UdiWWW.