There never has been an edbrowse windows user and there may never be.
As others have pointed out on this list, edbrowse dovetails with other command line tools in a unix or even mac environment,
and isn't nearly as useful on windows.
In other words, it is sometimes edbrowse plus other things that provides the power.
So why did we bother one might ask?

Well, at times I had dreams of getting grants, actually getting paid to work on edbrowse, and maybe subcontracting to some of you as well,
and grants are easier to get if you can claim your software runs on every platform.
Believe me the whole blind industry is windows centric, jaws, nvda, window eyes, on and on.
Rehab and employment centers teach windows and only windows.
So it was mostly for marketing.

But it turns out I can no more get a grant than I can swim the ocean.
It's just not one of my skills.
So if we give up on that, then I really don't worry about the windows port much any more, unless it is easy to maintain.
I've learned a lot though from it, and I thank you for all your hard work,
plus your continued tidy support.

Certainly switching to threads and away from fork and processes and wait and so on makes it easier.

An easy test is

edbrowse www.nasa.gov

That exercises all sorts of stuff, including a dozen javascript files which are fetched and loaded in parallel by threads.
If you get about 170 lines of stuff

=
170
,p

then it's all good.

You can watch the fetches in parallel and other things at debug level 3

db3
ub
b


Karl Dahlke