Eight-year-old bug in Microsoft's 64-bit VBA prompts complaints of neglect A compiler bug in 64-bit Visual Basic for Applications (VBA) on Windows has existed unfixed for years, a user complained, and is blocking migration to 64-bit Office. The problem – reported by a StackOverflow user – is in code that runs correctly in 32-bit VBA but not in the 64-bit version. There are documented reasons why VBA …
No. Just no.
You are not a nanny, you are a company with a product. If the user buys the 64-bit version, it's his choice, not yours.
Your stupid attitude and excuses might be valid for home users, but we are talking migration here. That means business users.
It's not up to you to decide what a business actually needs. And because you're selling the same product to anyone who buys it, that means that business users can buy home versions. Sure, they shouldn't, but you're not really blocking them from doing so.
So stop deciding for your users. That despicable attitude is why Windows' behavior changes over time : you're trying to "optimize" the OS during usage, and it doesn't work. All it actually does it make the computer slower for no good reason.
My pet peeve right now is the 75 seconds it takes to open a network share and get the file contents on screen. Right at the start, it states clearly that are NNN files in the folder, but the actual file names trickle in a dozen at a time. I have an old Win7 PC and, when I open that same folder, the results are instantly displayed on my gigabit network - like they should be.
Microsoft : what the fuck are you doing ? Whatever it is, stop it !
I've found other issues with 64-bit VBA - not that one - mainly in that it can suddenly become very slow compared to 32-bit VBA. Not sure exactly how it happens, but opening a new Excel instance will be fine to run, while an old one will crawl.
Add to this the fact that they still haven't fixed a page numbering bug that's been around since Word 2.0c, and it just makes me wonder what exactly they think they're playing at with Office.
That said, they have always been high handed regarding user issues and feedback. Their approach has always been "we know best, if we say it's not an issue, it's not an issue. Now go away while we put another three buttons on the toolbar you can press by accident, all of which will risk you losing all the work you've just done over the last half hour"
Microsoft made both versions available, so users who care could choose.
Since many (most) users are non-technical and don't understand the choice, Microsoft recommended the version they thought would work best. Most users would have gone with that choice.
The problem is 3rd party vendor addins. A lot of vendors simply can't be arsed to do 64 bit versions. Many will explicitly state that they only support 32 bit versions. In some cases, the vendor no longer exists. Of course it doesn't help if you get a vendor that is trying like in this case, but is held back by a bug in office.
The advice we give clients is try 64 bit version first, but if 3rd party products that tie into Office don't work then you may have to revert to 32 bit.
You would think that, what with COM being specifically designed as a cross-platform inter-processor network protocol, you could arrange to communicate between 32 bit and 64 bit processes. And you can. But only if you create a 64 bit object to do so.
The problem is that (with a few exceptions) MS had no interest in exposing even their own 32 bit objects as 64 bit objects.
This means that any VBA project which used external objects -- one of the prime use cases for VBA -- is automatically broken when run as a 64 bit process.
Ditto, in Win7 I could type: win //myservername/path/to/my/files return and bang! there. On Win10 it's win //m swallowed up while start menu opens //myser search box opens, bugegry off dammit, //myserver hold on why don't we search the network, no!! dammit /pathto/my/files wait 30 seconds errorbox dammit, it's swallowed one of the / characters. ARGH!!!
My guess with that one (which has hit me many times) is that the programming call that creates the folder creates it first with "new folder" as the name, and then performs a second call to rename the folder. And due to write caching vs read caching, you get a mild race condition where you are trying to open the folder by it's new name before everything catches up.
It's probably in the same class as the bug I ran across in windows 7 and has yet to be fixed in the GUI with moving folders with a lot of children objects (folders, subfolders, and files) in it. One of those things where it's faster to spawn a command prompt, map the UNC path to a drive letter, move the damn folder, unmap the drive letter, and close the command prompt then wait the several to many minutes while the GUI walks the file tree for that folder.
Now, I could see where it's checking to make sure that things like file path limitations aren't being violated while it's doing so, but it never says it, it just sits and spins and gives the appearance that it's not doing a damned thing when in reality it's actually gone and done it, it's just doing something in the background to make sure it did it safely. An annoyance at best.
It is very important to remember that Windows 10 defaults to SMB2/3 and has SMB1 disabled OOTB. Win7 was...exactly the opposite.
If any device on your network is communicating exclusively using SMB1 it can cause all sorts of these types of problems. Have you re-enabled SMB1 on your Win10 box[es] to see if this mitigates the browsing issue?
Sorry about that. Does forcing the binding of NetBIOS to TCP (change from DEFAULT to ENABLE, in the WINS property of IPv4 for the network adapter) change anything?
You may have the classic Winsock corruption, fixed with
netsh winsock reset
from an elevated command prompt.
And if that doesn't work, I'd try (the also classic) point of first deleting all protocols and clients that are bound to the network adapter, then completely delete the adapter itself from the Device Manager. Then reboot. That will force a rebuild of the network stack, hopefully placing the stack in the correct configuration.
I'm not convinced that enlarging the dependency surface to include a bunch of JavaScript frameworks outside of Microsoft's control will result in greater stability.
If your organisation has migrated away from local IT provision to Office 365 or Google Workspace or whatever, how do you develop and deploy your business-specific functions in a way that preserves your investment going forward?
SQL does it all the time: True, False or NULL and indeed the resulting 3-valued logic is the source of innumerable problems. But at least that's going to be consistently shit across runtimes.
Behaviour that changes like this across runtimes is a material defect and a class action would be reasonable.
Quite. It's a key feature of relational databases designed to deal with missing data.
Let's give the classic example. If you don't know your blood type, you really don't want to be given a blood transfusion of another unknown blood type. NULL does not equal NULL.
That sentence "a function that should return false will instead return true." is not correct.
If the result of that function is used in an `If` statement that `If` statement gets always `True`. If your sentence was correct and `ReturnFalse(New SomeClass)` would return `True` then the result of `If ReturnFalse(New SomeClass) And False = True Then` would be `False` because of `False = True` beeing always `False` but that `If` statement still gets `True`.
So the `Class_Terminate()` does not make the function return `True` but it breaks the evaluation of the `If` statement or the evaluation of the `Loop` condition where the function it is used in. The function `ReturnFalse(New SomeClass)` always returns correctly `False` and that is why `If True = ReturnFalse(New SomeClass) Then` fixes it, because the compiler is evaluating that differently from `If ReturnFalse(New SomeClass) = True Then`.
Ahhh... VBA. I had a love-hate relationship with that at a past job. It was a horrible tool for almost everything I used it for, but it was also the only automation tool the company would allow me to have. Even then it was only because of an oversight on the IT department's part not going in and removing it from the default Office install.
FWIW, a late friend of mine who stayed at that company after I left, and inherited maintaining some of my tools as the only other person who could code, was always telling me about how PowerShell let him do almost everything VBA could do, so might be a possible alternative for some. Maybe not as convenient, but you're probably infinitely more likely to get Microsoft to fix bugs in PowerShell than VBA.
IMHO, Powershell is worse than VBA as a "language". However, MS has exposed almost everything imaginable via .NET, so, in spite of Powershell's annoyances and shortcomings as a "langauge", it's still the better hammer to use when you've got a box full of screws. Just my opinion on the matter.
Is a lack of new flaws a sign of neglect?
Why does nobody make it worse,
its just disrespect.
30 long years
then into the ditch
I think msoft finally
made me their bitch.
Bad as they've ever been.
I think I just slam-poetry'd microsofts product management lifecycle.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
