Windows 11 - any problems noted? 1

[GriffMG]

I just upgraded my lappie to W11, thinking that customers will be pushed to do so soon - as with W10, and not wanting any unforeseen issues to bite me!

I cannot see anything life threatening... any gotchas I should be looking for? like the fix for general fields required in W10?

 

[herbstgy]

I just upgraded recently, too... so far, it works surprisingly well!
and it's easier on the eyes than W10 in my opinion.
anyway, you might wanna check this, if you don't want it to talk behind your back:

O&O ShutUp10++ - O&O Software GmbH

www.oo-software.com

 

[GriffMG]

I have spotted that ver brings up windows 10, and winver windows 11

 

[Paul Gibson]

For us, we've supported our applications on Windows 11 for as long as it's been out and I only know of one issue that appeared to be unique to Windows 11 and that was a laggy OS problem regarding generating a file. This particular issue could have been due to Adobe rather than Windows 11 but the problem only existed for Windows 11, no Windows 10 or previous OS showed this problem. I'll try to briefly describe it...

Our VFP application has used Adobe integration to generate PDFs for well over a decade, maybe even two decades. It uses the method where it runs the VFP report, specifically pointing to the "Adobe PDF" software printer and this generates a PostScript (PS) file. When the first-step is complete the integration continues, taking the PS file and automating the Adobe Distiller to convert the PS file to a PDF file and that's it.

I know there are probably other, potentially better, ways to generate PDFs from VFP - we actually do also use FoxyPreviewer (FP) - but this Adobe method has been working for much longer than we ever had access to FP so plenty of users do use that method.

Anyway, that 2-step process generally works fine, as long as the Adobe components are correctly installed, licensed and the settings configured. On some Windows 11 machines, not all I hasten to add, the issue we had was that the first step had a significant lag where the command to generate the report as a PS file completed, returning control to the VFP program to proceed to the following code lines, but the PS file would not actually show up in the destination folder for some extra time. It was never long, maybe not even a second, potentially just a few dozen milliseconds perhaps but whatever the delay, it was big enough to break the two-step process. Computers are fast so if the REPORT command completes, then moves onto lines which check if the PS file exists and the file hasn't arrived in the folder yet, because of the lag, then that's a problem.

The user experience of the problem was that they would try to generate the PDFs and they'd always get the message that the system was unable to generate the PS file but if I checked their machine the PS file would exist and that's how we worked out that the PS file was being generated but the file lag was causing the program to check for the files existence before the file existed.

The solution was simple, we had to code a "check for file and wait a bit" loop routine so instead of just a simple FILE() or ADIR() check it would go into the routine that would check for the file and if it didn't exist, just do a short wait, like 100 milliseconds, check again and while the file can't be found keep looping for a set time limit, like 2 seconds. Only after the limit has been exceeded then return that the file failed to be created but if it did create (and it generally does) within that limit then proceed as normal.

As said, we only had to employ this method after some of our users started reporting the problem and every single report of the problem was on Windows 11, without fail. It's just standard practice now, that PDF generation procedure always uses the "check and wait if" routine instead of instantly checking and potentially failing.

Other than that I can't think of anything else that Windows 11 made us do differently.

 

[GriffMG]

Thank you Paul

 

[Gary Sutherland]

I've found the screen scaling messes with the positioning when sizing forms, etc, when programming.

 

[Piotr Czekalski]

In VFP 6.0 the "$" clause was causing problems for one of my clients.

X="A"
IF X$"ABCD"

EndIF

I replaced it with Inlist()

Maybe it was a special case. I don't remember the details. It was about a year ago.

I confirm necessity of using 100,200 millisecond slowdowns for File() and ADir() to check if a file or folder has been generated (regardless of Windows version).
I expect problems with handling DBF tables in a Microsoft Windows server environment. I had problems when changing Windows 7 to Windows 10. On Linux servers is OK .... as always ;-)

 

[Dan Olsson]

I have about 150 clients at about 40 different places in Sweden.
All have the same setup with the program and data on a server share.
ONE of those clients was upgraded(?) to W11 and she immediately complained that everything got very slow. Everything worked but took some 3-4 times longer to do. I mailed everyone and warned them about the problem. I never resolved why

 

[Piotr Czekalski]

Dan, it may be a coincidence. Maybe it's the network switch's fault. In my case, 99% of network speed problems are caused by network switch failures. Another reason is incorrect network card configuration. I don't know much about this, but maybe Windows 11 has configured the card incorrectly? Maybe it has changed the network transmission speed to slow ?

 

[GriffMG]

I have noticed one thing, since I upgraded the BSD has appeared twice already... it had largely stopped some time ago when I upped the RAM to 64GB

 

[tomk3]

We do not have problems (yet ) , except :
Windows 11 has an option "windows may change default printer". We recommend to disable that if you have little label printers and A4 printers and create PDFs via Foxyprviewer.

 

[Chris Miller]

I don't see anything really new here.

How could $ can even be OS related? No offence, I have had similar problems once with VARTYPE() to be fixed by using TYPE() instead in VFP6/7, I do believe you actually had the problem, therefore, but it can't be OS related, $ just like TYPE() and VARTYPE() have nothing to do with the OS, VFP doesn't use any OS API functions for these VFP operators and functions, so there can't be an OS dependency.

OS() itself has no parameters in VFP6, but in later versions offers better OS version details. Nevertheless,even the VFP imaging blog had an article on that: https://vfpimaging.blogspot.com/2021/04/getting-correct-windows-version-os.html
There are more options, like a WMI query of Win32_OperatingSystem.

That you don't directly detect file existance in VFP has been a problem discovered using PACK since Windows Vista, which you therefore better replace with code copying the data into a cursor, ZAP the DBF and APPEND from DBF("cursorname") or more safe options using a backup and temp table DBF file (safe against power outage). Anything creating files by a second process also is treated best by waiting for the file and maybe up to the point you can fopen it with write permission.

Windows default printer automatic change feature I think I know since Win10.

Network card and switch not negotiating the best transfer rate is a network thing and was always a problem, if it's misconfigured, outsie of any OS or VFP dependency. If you have a problem there it's more likely due to a new and not optimized erver than due to clients.
Then within the network performance there's the opportunistic locks problem that can come back with client/server changes, as you lose the registry entries controlling the damage and forget to reapply them. Or even need a new set of reg keys. Maybe that's due now or soon.

BSD, well, that's surely OS and Hardware. Long time no see, for me. I take it from here Win11 needs large RAM. No big surprise to me, though I had the impression MS was rolling back on Hardware demands also for graphics, because of the change from Aero to flat design, too.

So the only thing I consider a new problem in recent times was default printer and the general field problem under Win10. Whereas avoiding general fields was recommended since at least the times of Win XP, it's always a bad idea for images, you would therefore only need it for other OLE objects like RTF Text, I think there's a well known way to use RTF in VFP reports with a general field and olebound, i.e. olecontrol within a report. There's the only need and only terporary need for general fields for things like that in reports. And that was a bummer within Win10, as it didn't even worked for that temporary usage. The core problem usually was that ole servers are not the same across Windows versions, if you used general fields to persist data and then use it on a new OS, but that was recommended against for very long, already. Up to Win11 you never had this problem within the same client using general fields for OLE objects locally and termporarily, though.

The default printer doesn't bite you, if you go bya the well known mehanism of installing a printer driver with a dedicated name, also to manage differrent configurations, different paper trays to use, for example, and the SET PRINTER TO NAME knownname instead of using the default printer.