OpenEuphoria

1. Another Win32lib problem, and this may not be fixable. Fixed - sort of....

• Posted by ChrisB (moderator) in August
• 1356 views
• Last edited in September

Hi

I was away on holiday when the win32lib not working thread appeared, so couldn't really get involved, glad it's more or less sorted.

However when I got back I thought I'd better just check it out to see if there was a problem with the download.

Oh dear, I got the dreaded freeze - flashing console cursor, and stuck on that for ever, needing to close via task manager, with no feedback as to the actual issue.

This usually boils down to a library / dll issue (error in the dll not with eu), and also often because of a wrong parameter.

SO I went down the rabbit hole of tracing the paths through win32lib (puts(1, "Hello(01)", ? parameters, printf(1 "Parameters"< {})) until I tracked it down to printing and w32pool, and the winspool.drv.

I recently updated windows 8.1 (I was one of the minority that loved it) to windows 10 (it's ok, but the computer is 10 years old now, so it occasionally lags). I also got a printer at the same time - so that's 10 years old too, an Epson SX235 - works great, no reason to change it. I re installed drivers for Windows 10, and it seems to work fine, except sometimes it doesn't.

The windows printer driving system has also changed, there's a different style of print dialogue now. Programs designed for win 10 work fine, and bring up the new dialogue, legacy programs just freeze when trying to print, and need to be shut down from task manager.

Getting back to win32lib, the printer and printing seems to be so tied in very intimately to the program, that it's going to be extremely difficult and tedious to tease it out, put it in a aseparate include, and set a flag as whether to include it or not.

As I see it there are a couple of issues here. The print dialogue has changed in Windows so that eu isn't talking to the new style dialogue. The old style dialogue isn't being brought up by eu / win32 lib (winspool.drv). The epson SX235 may have installed a winspool.drv that can't be used by eu / win32 lib / Windows 10. The dll/drv is silently crashing and not letting eu know.

Other eu programs work fine. I fact non printing win32lib programs that I made on win 8.1, and bound, also works fine. Binding removes unused routines and functions, so obviously printing functions have been removed at binding time.

Investigations are ongoing. I may install a modern printer. I will try to tease out the printing entanglement to see if I can flag it on or off.

Has anyone had similar issues, or any thoughts on the way forward

Cheers

Chris

3. Re: Another Win32lib problem, and this may not be fixable.

• Posted by Icy_Viking in August
• 1316 views

Hi Chris,

I found this https://katfile.com/oaqj2hl0krx9/Win32lib.zip.html

Its a Win32lib for Euphoria 4.1.0+. It works for me, the demos run fine. I haven't really developed with Win32lib in awhile though. I have thought about writing a new win32lib with a more modern Windows API that would also include things like a DirectX wrapper included as well. Of course that is no easy task and it would be a huge task to to get the windows API wrapped again. Not saying I'm against it, I wouldn't mind starting it, but I doubt I could do all the work myself.

Also, it looks like you did some work on this version of win32lib, Chris. I'm not sure where I downloaded this from, but its been in my Euphoria collection for awhile. I should mention I'm on Windows 11 Pro 64-bit

5. Re: Another Win32lib problem, and this may not be fixable.

• Posted by ChrisB (moderator) in August
• 1311 views

Hi Andy

Sadly, same result, thanksthough.

I'm moving more and more towards a win 10 / winspool.drv issue.

If you look here https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/winspool/ these functions don't exist in win32lib

and here https://www.google.com/search?q=windows+10+printing+from+legacy+programs

you'll see theres a lot of info about legacy drivers, old style print dialogs, and new style dialogs, and various things to try (tried most of them)

So I think what's going on is that winspool.drv is being opened ok, but the dll is crashing when a function is being called that doesn't exist, or winspool.drv is 64 bit, trying to be called from a 32 bit eu.

Unfortunately no win64lib to try, but I may try a more modern printer, sometime.

Don't know what the solutionis.

Cheers

Chris

7. Re: Another Win32lib problem, and this may not be fixable.

• Posted by ChrisB (moderator) in August
• 1243 views

Hmmm, I guess I should really do something about printing on Phix. About 20 years ago I wrote a rather ambitious Print Preview module, win32lib-based, maybe I could try resurrecting that.

I pretty much lost track of things back when printers started getting connected via USB ports... I have no idea where this may take us but this needs solving properly, so let's just get stuck in.

Have you tried running your program on Phix? Is there any source code available?

• not yet, its win32lib though, so the source code's there. Will try on Phix.

Have you tried trace(3), see if that drops any clues where to start looking?

• No

Can we be sure that none of the define_c_func/proc/var() are yielding -1?

• Yes - it's the dll/winspool.drv that's crashing - if theres a 32 bit (legacy) winspool.drv

Can you print a test page via, say, Notepad? It makes sense to rule out hardware/driver issues.

• Yes, the printer works fine, and prints from programs written for win10, using the new printer dialogue. (see the google link above, win 10 has modern and legacy print dialogues) Older 32bit programs using the legacy printer dialogue also crash (or as windows says, 'not responding')

Are there any win32lib printing docs worth reading to be had?

• not really, it all seems to be handled through winspool32.ex, which actually has a fairly limited function list. Plus I've printed out returns from the opening of winspool.drv, and they look reasonable, but the freeze happens when you try to _call_ a function or procedure within the .drv (=dll).
  
  Is there anything on www.rosettacode.org or board.flatassembler.net or similar that might be useful? Sure, I'll have a scout around myself, but extra eyes cannot hurt and anything that can easily be built and works would be a huge help. Separate examples for Windows and Linux are wanted, at least here.

• Will carry on searching through there as well. As I said was thinking about stripping out the printer functions. There seems to be two camps - those that cannot print (me), and possibly those that have more modern printers, where win32 lib.

• In fact lets have a poll, if your win32 lib runs test programs, do you have an old or modern (meant for win 10) printer?

Cheers

Chris

9. Re: Another Win32lib problem, and this may not be fixable.

• Posted by ChrisB (moderator) in August
• 1151 views

Hi Pete, I spent the weekend trying to get it working.

I am more and more convinced that it's a dll issue with winspool.drv.

Used dependency walker to look at the function exports in winspool.drv. Sure enough the suspect functions - those linked in w32spool.ex - are in the driver, BUT winspool.drv has dependencies which are not satisfied.

looking at https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

You are not missing those DLLs.

Those DLLs are Windows's implementation detail and are subject to change at anytime. Basically Microsoft started moving around APIs starting from Windows 8. For example, APIs in Windows 8's api-ms-win-core-file-l1-2-0.dll got moved to api-ms-win-core-file-l1-2-1.dll in Windows 8.1. Old software still work because the dlls developer linked to are now just placeholders redirecting calls to the actual implementation. But nobody should link to the implementations directly, as that would be defeating the purpose of having such a redirection. Any software that report those dlls are missing are failing to accommodate the redirection (e.g. reporting a delay-loaded dependency as hard one).

Don't try to obtain those dlls. The only supported way to get those DLLs is to do a major Windows upgrade (e.g. from Windows 7 to Windows 10). Distributing those files is against Windows end user agreement, and those files you get from a higher version of Windows won't work if your Windows version is too low.

If you are a developer, just use the APIs documented in the Windows SDK (unless absolute necessary like writing antivirus) and do not take any dependency on those dlls, as they may only exist in one Windows version. Those APIs may or may not use the DLLs you listed, but their dependencies are not yours to worry. You should only depend on documented APIs, not implementation details like the name of those DLL. E.g. instead of taking a direct dependency on api-ms-win-core-file-l1-2-0.dll you should take a dependency on kernel.dll which supports Windows 7 as well.

So I think I'm going to give up, try a a new printer (it is a very old printer), and if that fails, rewrite win32lib (!). I'm not writing a new printer driver.

Just discovered another issue, Windows 10 (one of the upgrades H22 or something) loses printer sharing, so I can't print from another computer. Fun times.

Cheers

Chris

11. Re: Another Win32lib problem, and this may not be fixable. Fixed - sort of.....

• Posted by ChrisB (moderator) in September
• 912 views

Hi

So after many a late nights and thinking time driving back and forth to work, I nailed the problem to winspool.drv, DocumentPropertiesA, being a non returning blocking function in the winspool.drv. My suspicion is that it's a winspool.drv installed by the old printer installation, which is in actual fact causing problems for all 32 bit programs using it.

So the solution is not to call these functions, by setting a flag in w32lib that says either allow or disallow winspool calls, and so far, touch wood it works - tested on various w32 lib programs, and the mother IDE too. At least I can create win32 forms using the IDE now.

Most users will set WINSPOOL_ALLOWED to 1, but if your w32 program freezes (not crashes), try setting it to 0. There is some debugging stuff left in there too if you get curious, and look in w32winspool.ew w32dll.ew and w32resources.ew (although the errors don't happen there, a lot of calls to printer functions are in there)

I will upload this to my box.net, with WINSPOOL_ALLOWED = 1 set, so for most people no difference.

I was a little curious myself - this seems faster

    if funcid = spoolFuncs[1][1] or 
        funcid = spoolFuncs[2][1] or 
        funcid = spoolFuncs[3][1] or 
        funcid = spoolFuncs[4][1] or 
        funcid = spoolFuncs[5][1] or 
        funcid = spoolFuncs[6][1] or 
        funcid = spoolFuncs[7][1] then 
            WINSPOOL_FUNCTION_FOUND = 1 
end if 

as opposed to

            for i = 1 to 7 do 
               if funcid = spoolFuncs[i][1] then 
                   --showspoolFunc(i) 
                   WINSPOOL_FUNCTION_FOUND = 1 
                   exit 
               end if 
end for 
 

Is it?

Remember there will be a lot of iterations of this (every time a c_func (w32Func) is called), and the loop just seemed slower to me (especially with the IDE).

Feedback / issues appreciated. Adding on to that if anyone else has made any changes, would be happy to incorporate them if you want.

Link https://app.box.com/s/aobv6tpdkk5suz5g66xk4p7iwujfd0cv

Cheers

Chris

13. Re: Another Win32lib problem, and this may not be fixable. Fixed - sort of.....

• Posted by katsmeow in September
• 867 views

15. Re: Another Win32lib problem, and this may not be fixable. Fixed - sort of.....

• Posted by petelomax in September
• 841 views

My guess would be that the first condition of the if statement leaves a spoolFuncs ref (and probably funcid) in a register which the next six tests can use, whereas the loop reloads every iteration and consequently suffers up to seven times as many AGI (address generation interlock) stalls. Even so, I'm a little surprised you noticed/actually managed to measure any difference, though I guess that makes more sense if all seven tests are failing ~99% of the time. There are plans for a proper register allocator in Phix 2.0.0, should that ever happen.

Actually, for i=1 to length(spoolFuncs) might be an improvement over for i=1 to 7... unless the compiler knows it's always 7 and optimises that length() call away...

17. Re: Another Win32lib problem, and this may not be fixable. Fixed - sort of.....

• Posted by katsmeow in September
• 834 views

I wrote something, then decided i didn't want to argue over creole again. I'd rather point out again that googleapis is required to preview posts.

Kat