Hi Michael,

...

There is not new feature against original one though, I just mimicked it as well as possible. The motivation here was, I wanted to understand the mechanism under Squeak plugin deeply, and Andreas told me his original source code was missing in one of his old hard disks ;)

Ouch... That is bad that you wasted your valuable time because of this miscommunication. Andreas found some not quite up to date version that Bernd worked on recently. Isn't the source in the repository?

Michael

Oops, I should ask Andreas at first...

At least, it was a good exercise for me because it was almost my first Win32 API programming experience. And still I'm very interested in how activeX plugin was implemented.

Cheers, - Takashi

On Nov 22, 2006, at 9:44 , Andreas Raab wrote:

Takashi Yamamiya wrote:

...

Oops, I should ask Andreas at first...

No problem and thanks for reminding me. I just did a "quick fix" for the problem that is commit the code that I found to squeakvm.org repository:

http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/vm/ Plugin/

This includes the netscape plugin (under NPSqueak) and the ActiveX control (under SqueakOCX2 - the other one was an older version that didn't support the url fetching mechanisms etc)

Great! We also need to get in the fixes in that I added for the Unix version (attached) and which impara ported to Windows.

...

At least, it was a good exercise for me because it was almost my first Win32 API programming experience. And still I'm very interested in how activeX plugin was implemented.

In unspeakably ugly terms. ActiveX is nothing for the faint- hearted. The code requires magical MSVC invokations that I'm not even sure recent versions will handle correctly. YMMV.

Impara managed to rebuild the OCX recently, with one fix for fetching long URLs (was limited to like 200 characters or so). Not sure which MSVC version they used, though.

- Bert -

On Nov 23, 2006, at 2:33 , Andreas Raab wrote:

Bert Freudenberg wrote:

...

Great! We also need to get in the fixes in that I added for the Unix version (attached) and which impara ported to Windows.

So what was the problem? The diff doesn't make much sense to me given that I don't know much about the unix implementation of that stuff ;-)

There were two major problems.

The first does not apply to Windows. It was a bug in the Unix browser plugin in the pipe communication with the VM. There was an error return code ("resource temporarily not available") on Solaris that I never got on Linux, so it was not handled correctly. The symptom was that after the Squeakland "project laoding" splash screen the screen turned grayish. Took me a while (debugging over the phone) to realize this meant the VM simply had crashed. Since I could not reproduce it, I was actually flown in to Colorado to debug on-site. Turned out it's an EAGAIN error and the cure was to, err, try again. Like, 50,000 times.

The second issue was a cross-platform Mozilla bug, I reported that as #359801:

https://bugzilla.mozilla.org/show_bug.cgi?id=359801

The symptom (which I had seen a few years earlier, but never investigated in depth) was that inexplicably, some bitmap files could not be fetched through the browser API. The workaround I implemented was that if the regular fetching as file fails, I do the call again, but this time using the streaming API, streaming to our own temporary file. Nothing on the Windows VM side needs to change for that, the temp files are deleted when the plugin exits (on Unix, the VM deletes the file immediately after it was opened).

...

Impara managed to rebuild the OCX recently, with one fix for fetching long URLs (was limited to like 200 characters or so).

Oh really? Probably some MAX_PATH confusion.

Yep, that was it - it caused the CombineUrlSomething error we mentioned a few weeks ago ...

- Bert -