[RESOLVED] VB6 0xc0000005 on Windows 11 after calling *any* API

Hi gang, I'm using Windows 11 Build 20000 co_release 210604-1628 - Running in Developer Mode, Always run updates, using only Windows Defender for antivirus, excluded my source code folders from scans.

VB6 ran fine on Win11 until VS2005 (seemingly random) started trying to re-install from source media, every time I opened VB6. So I uninstalled VS2005, and VB6 quit working completely. So I uninstalled and reinstalled.

Now, VB6 loads fine (no App Compatibility settings), opens (As Administrator) any project. If you run (F5), the entire IDE disappears. If you step through (F8) it will execute any type of VBA code until it hits an API (doesn't matter - kernel32, user32, custom dlls), either declared or through a type library, and then the IDE disappears.

Windows logs show:

Faulting application name: VB6.EXE, version: 6.0.97.82, time stamp: 0x403acf6c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005 (Access Violation)
Fault offset: 0x0a8bac64
Faulting process id: 0x17c4
Faulting application start time: 0x01d954271a804c69
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE
Faulting module path: unknown
Report Id: 901c5960-2f4b-4ee8-a928-ecf8be31a316
Faulting package full name:
Faulting package-relative application ID:

VS6 C++ has, and always runs fine, installed via - https://www.codeproject.com/Articles...dio-on-Windows

I've done SFC/scannow, uninstalled, reinstalled, cleaned registry, google searched everything.

I am out of ideas... help.

If this were me, I'd do a fresh install of the entire OS and be done with it. This sounds like a big ole mess and trying to clean it up will more than likely prove more troublesome than just starting over from scratch.

Quote:

---

Originally Posted by Niya

If this were me, I'd do a fresh install of the entire OS and be done with it. This sounds like a big ole mess and trying to clean it up will more than likely prove more troublesome than just starting over from scratch.

---

I thought about suggesting that, but didn't want to go that drastic. I think you may be right though.

Quote:

---

Originally Posted by Elroy

I thought about suggesting that, but didn't want to go that drastic. I think you may be right though.

---

Well, I can tell you from experience that trying to solve problems like this can lead you down rabbit holes of unimaginable depths and to places that may cause some discomfort. Most of the time, you will still fail, even after all that and have to re-install anyway. My suggestion offers to skip right to the end of the story without the painful journey :D

Before trying anything so drastic as to re-install the OS, have you tried re-installing VS2005?

Quote:

---

Originally Posted by 2kaud

Before trying anything so drastic as to re-install the OS, have you tried re-installing VS2005?

---

Thanks for the suggestion, it was something I never considered. I tried. But still no dice. Let this be a lesson: Anytime you get 25 year old software to work on a modern system, make a system image so you can go back in time quickly. I am dreading the reinstall, so I will probably tough it out on my Win10 laptop. Thanks folks!

You can try system restore first, if you have a restore point before it went belly up, that's gotten me out of a few jams with crashing system components without reinstalling Windows. In the future, you'll likely want to set up more frequent restore points than the system default. I've got it set to make one every 3 days now.

Note that this will delete any exe on your main drive that's been put there since the restore point, even in deep build folders of your programs.

A partition clone once a month or so is much more valuable than a restore point. In fact I even question the helpfulness of restore points and they are disabled by default anyway on any new installation.

At least once a year restore points have gotten me out of situations where Explorer crashed if you touched *anything* after loading a folder or doing anything with context menus. This is likely an issue with a corrupted registry, binary, or system file, and that's exactly what restore points are great for.

Full images once a month sound like a giant pain. I'd rather just backup all my personal data and then worry about the once-a-decade having to set things up from scratch (so long as you have restore points to solve more common problems).

I know you're right before I typed this SOS to begin with. I've got a year of programs and settings on here. Ouch. Cry. Whine.

Gang, I'm going to end this on a happy note. I'm not going to reinstall Windows.

I'm instead going to support @WaynePhillipsEA, TwinBasic - https://twinbasic.com - with every fiber of my soul.

I pray that he has all the coffee he needs to bring VB6 kicking and screaming into the 21st Century.

GAME ON TWINBASIC!

If twinBASIC isn't crashing on the same calls it's almost certainly a VB6 problem rather than a Windows problem. Maybe something like the 'Clean system' option on VS6 Installer to wipe out all the VS6 files and registry entries the regular uninstall misses. Also, you're installing it with SP6 right?

But yes tB is getting closer and closer to full compatibility-- it's able to run a lot of large, complex apps unmodified; you should definitely support it if you want a modern future for the VB6 language.

I made a list of the extensive set of new features that are *already* available in it... so outside of projects that depend on one of the few missing things there's already a ton of good reasons to start developing in it instead.

Attach the crash dump. I suppose it's because the DEP is enabled. You can disable DEP for VB6.exe and try to run it after restarting Windows.

Quote:

---

Originally Posted by The trick

Attach the crash dump. I suppose it's because the DEP is enabled. You can disable DEP for VB6.exe and try to run it after restarting Windows.

---

You were absolutely right, TRICK, it was the DEP. Chalk up another victory, you are definitely a mad scientist. I'm a fan of your music, as well.

TLDR: Skip to (Step) 4.

First off, I want to thank everyone who responded. This is the absolute greatest site for VB6 junkies. It's impossible for me to give up 25 years of knowledge. That's why I'm ultimately rooting for TwinBasic. I don't want to compile to pseudo code or CLR or anything else that isn't machine language; it is a performance hit until Quantum computers are the norm, and by then AI will rewrite all of my VB6 code to run on those platforms (If I live that long).

I will re-iterate my stupidity by not making a system image when everything was working. VanGoghGaming is right. I have about ~200 programs and 100 plugins (I'm a video editor and audio engineer), endless preferences, endless hours setting it all up. Reinstalling is really not an option. I'd rather buy a new system or use my ancient laptop to run VB6. I just like this machine, cuz it's fast, and I enjoy being a Detective for fixing stuff in Windows.

I don't know how to mark this issue as [Resolved], but here's the path I took to fix the problem on Windows 11:

1. Control Panel > System and Security > System > Performance > Settings > Data Execution Prevention "Turn of DEP for all programs except those..."
I added every single executable (*.exe) in my VS6 folder to the list. //= Shotgun. //== Nuclear Blast... (just a joke for those humor blind... it's quite common these days.)

//=THIS DID NOT WORK!

2. Found a random post on google about "REALLY CONTROL DEP" with bcdedit.exe = Command Line > Administrator > bcdedit.exe /set {current} nx AlwaysOff

//==THIS DID NOT WORK!

3. Then I found this thread on vbforums - where The Trick called it, 7 years ago... Some things never change.

//===ALMOST THERE, GETTING CLOSER...

4. NSFW - DO NOT ATTEMPT TO THIS FIX YOUR COMPUTER CONNECTED TO YOUR OFFICE NETWORK.

Yes, I'm talking to you, government employee still trying to keep some ancient VB6 program alive... or your IT guy will murder you! (Special thanks dilettante for reminding me not to short circuit security as a practice):

I had never heard of EMET, so at the start menu, typed EMET, and the last search result was "Exploit Protection" clicked that, and changed that to "Off by default" > Reboot

5. Start VB6, opened up my beautiful precious baby project, [F5] and... drumroll... [SHAZAM!]

//===== IT WORKS ! ! !

Now I can go back to work on my audio stuff. It really just bugged me that it didn't work on this machine, after all this drama.

Thanks again, Trick, for pointing me in the correct direction for my purposes, and your constant contribution to this site.

Thanks fafalone for all of your incredible work on oleexp and now TwinBasic, you're a star.

//====== CONCLUSIONS

1. Enabling "Developer Mode" in Windows 11 does absolutely nothing for the developer, except for enabling Defender to become spyware of your development activities. I've had at least 4 pleadings from M$ after running examples by The Trick, and others "Please send us this code so we can examine it". I have a .txt file they have tried to get permission to investigate, and it's just a hosts file of M$ IPs I have blacklisted.

2. Do not enable "Developer Mode" in Windows 11 and you'll be happy.

3. Start the migration to TwinBasic and pray M$ doesn't put it into their crosshairs.

Cheers, Tai Shan

Quote:

---

Originally Posted by taishan

[B]
I don't want to compile to pseudo code or CLR or anything else that isn't machine language; it is a performance hit until Quantum computers are the norm

---

I don't want to turn this into another VB6 vs .Net thing as I'm pretty over it by now. But it really grinds me when misinformation like this still persists. CLR platforms like .Net execute native code, not P-Code. There has never been a P-Code interpreter for the CLR. Also, there are many vectors now available to the .Net programmer to produce native code that is typically much faster than naive VB6 implementations.

For one thing, the compilers tend to use modern vector instruction sets and you can even explicitly ask it to do so through certain types. Another huge thing is the addition of ref structs and spans to C# which enables you to perform some pretty amazing optimizations that are unsupported in most languages. For example, take this:-

Code:

---

a = Split(myString, ",")

---

It is possible to write a version of that in modern C# that allocates zero memory for the sub-strings which is a massive optimization. I'm only scratching the surface here. Spans and ref structs allow you to more easily produce blazing fast native code for many types of memory and CPU intensive algorithms.

Now I'm not saying that you can't write highly optimized native code in VB6, you most certainly can but it typically requires you to really know what you're doing like SAFEARRAY hacks, String hacks, VarPtr tricks, assembly thunks, trampolines etc. It's not baked into the language by default.

There's more I could say on this topic but I don't want to drag this on and on.

This is not an attack on you so please don't take it as such. I'm not even telling you not to use VB6 or TwinBASIC. They are fine languages, use them if you like. All I'm saying is that we need to stop perpetuating myths like that because it can be harmful. You might like VB6 and that's fine but someone else might be thinking about a .Net language and they read something like that and think it's true and it ends up affecting their decision on whether to adopt the platform.

The technical term may have been wrong but it's still a managed language depending on massive frameworks.

I'd be interested in some performance comparisons. It may be able to use newer instruction sets, but there's a lot of ground to make up when every few lines is a call to thousands of lines of .NET framework code.

Quote:

---

Originally Posted by fafalone

The technical term may have been wrong but it's still a managed language depending on massive frameworks.

---

This is quite true. However, what most people don't realize is that in practice, it tends to matter very little and many times, not at all. It's also very dependent on what you're doing. For example, you really would not want to write drivers in a .Net language. TwinBASIC and even VB6 would be far better because they can produce more streamlined binaries.

However, if you're writing say, CRUD line of business front end type applications with pretty UIs, you will probably find a lot of value in something like WPF that makes it easy. Lets say you want to quickly write and deploy a high performance HTTP API end-point from a Linux machine, you might want to look at .Net 6 or 7 with ASP.Net Core.

Also there are many options for customizing your solutions. You can write applications that are entirely self-contained and don't require the installation of the entire framework. There are certain compiler settings that make the compiler analyze your code and pull out only what you have used from the framework.

To generalize it, you would prefer VB6/TwinBASIC if you need tiny high performance native code binaries. Drivers are one example. Shell extensions are another example of an application type that have these restrictive requirements. However, if small binaries are not a requirement, .Net can probably cover you.

Quote:

---

Originally Posted by fafalone

...but there's a lot of ground to make up when every few lines is a call to thousands of lines of .NET framework code.

---

I've heard this argument too but I think this is quite a bit misleading. All of us are Windows programmers primarily and the Windows sits on top of a huge stack of abstractions. Even the most barebones C project on Windows is drilling down into thousands of lines of Windows code complete with all kinds of kernel/usermode switching going on. Yes, it's true that .Net adds a layer on top but that is a relatively thin and carefully designed layer which many times is completely eliminated by the compiler. Even setting that aside, one extra layer of abstraction would hardly add anything noticeable to the dozens of layers that you get by default just for being on Windows.

I mean just think of memory for example. Let's say you're dealing with byte arrays, it doesn't matter you're writing C, VB6, .Net or even x86 assembly code, all of them would drill down into the virtual memory system of Windows which by itself is an extremely complicated abstraction where you have page faults tripping all over the place, things being swapped in and out of memory to the hard drive, TLB look-ups etc.

Quote:

---

Originally Posted by fafalone

I'd be interested in some performance comparisons.

---

Well I'm pretty sure it's possible to write very performant code in VB6 that is comparable to anything written in .Net. The point I was trying to make is that the barrier to entry into this game is much lower in .Net. on account of all the tools it offers to do so like spans. The hardcore optimization game no longer reserved for only the Gods, mere mortals can play this game now too. ;)

You're really overstating the levels of abstraction in VB6 and understating it in .NET.

But yes if you don't care about performance, which is most apps these days with how powerful computers are, .NET has a ton of features. Features that will hopefully meet your needs because you're SOL if you wanted to modify them in any way.

Quote:

---

Well I'm pretty sure it's possible to write very performant code in VB6 that is comparable to anything written in .Net.

---

I don't suppose you have numbers to back up this attitude... I'd bet that you have to go very far out of your way in .NET to match VB6, rather than the other way around. If you went out of your way in VB6, into the techniques on vbspeed and asm thunks, spanning and whatever else you want to do in .NET isn't coming within a gigaparsec of VB6.

Actually x64 gives the quite performace boost so .NET exectuables will give the better performance i guess. Moreover .NET execuatebles have JIT compiler which makes the native code so the performance degrade should be only for the first run i guess. I'm not a .NET expert and i can be wrong.

Niya, I didn't make myself clear, and I don't want to dis the choice of your programming language. I wasn't implying .NET had anything to do with P-Code. I didn't use VB5 because of P-Code. I still used QuickBasic, Pascal, or Delphi.

I don't do managed code. Period. The day I found out TwinBasic uses a CLR or anything similar I will drop that like a hot potato.

I was forced to use VB6 and SQL in the late 90s. I then fell in love with VB. I don't want to learn a new language ---VB.NET and C# are new languages. I'd rather spend that time learning Java, or force myself to build the pyramids with C++. It was hard enough for me to learn VB at the time. I am not a polyglot.

The other day when I tried 2kaud's advice and reinstalled VS2005, it had selected a .NET obfuscator by default. That's a red flag for me. I don't care if someone decompiles my code but I want them to have the Trick's abilities to do it, not just any script kiddie.

M$ could've made VB 7 with all the stuff Niya loves about .NET in 2003. They didn't. I spent a year playing with Delphi because of that.

This is about M$ having COMPLETE control over what you write and when and where it gets executed. They are not the programmer's friend. They proved it in 2003. I could go on and on about how anti-competitive M$ with EVERYONE, but remember what they pulled on Netscape? Java? Linux?

Peace.

Quote:

---

Originally Posted by The trick

Actually x64 gives the quite performace boost so .NET exectuables will give the better performance i guess. Moreover .NET execuatebles have JIT compiler which makes the native code so the performance degrade should be only for the first run i guess. I'm not a .NET expert and i can be wrong.

---

I'm not sure x64 vs x86 is a fair comparison here since that's inserting the WOW64 layer too. .NET can build for 32bit; for 64bit, a more appropriate comparison would be twinBASIC x64, once the optimizations are available (though unoptimized tB x64 vs .NET might be interesting too). Or perhaps vs x86 Windows.

Quote:

---

Originally Posted by fafalone

I'm not sure x64 vs x86 is a fair comparison here since that's inserting the WOW64 layer too. .NET can build for 32bit; for 64bit, a more appropriate comparison would be twinBASIC x64, once the optimizations are available (though unoptimized tB x64 vs .NET might be interesting too). Or perhaps vs x86 Windows.

---

WOW64 layer is actual for API calls. I'm talking about processor instructions which are quite faster than x86-instructions. VB6 can't compile 64 bit binaries like .NET does. So .NET has the speed advantages due to x64-84 instruction set. Today i think few machines have 32-bit windows.

I welcome the prospect of compiling to 64 bit instructions.

For my purposes, I doubt it will help me play MIDI files with any greater precision than my current configuration of a C++ DLL called from my UI in VB6.

I've tried x64 .NET examples of MIDI players, and they stuttered unless calling the MCI, and then you lose control over playback... Maybe it was just a poorly written .NET example. For me, it's not worth deciphering a new language.

I'm still trying to decide if I prefer ULLI's FFT methods or the Trick's, for my goal of drawing the ultimate real-time audio spectrogram. The plugin that ships with FL Studio is cool, but I'd like to make a better one, just for fun.

I'd like to write a performance test of FFTs compiled in TwinBasic to a 64 bit .exe to see if .NET is faster. I seriously doubt it, unless it is written entirely in .NET C++, but I am guessing.

Quote:

---

Originally Posted by fafalone

The technical term may have been wrong but it's still a managed language depending on massive frameworks.

I'd be interested in some performance comparisons. It may be able to use newer instruction sets, but there's a lot of ground to make up when every few lines is a call to thousands of lines of .NET framework code.

---

Assuming every few lines involves thousands of lines of framework code is being a bit disingenuous to put it mildly.

The more modern versions of .Net do an awful lot to mitigate performance issues, newer versions are very different to the older versions in terms of performance.

When you look at newer approaches such as ReadyToRun (which is a form of AOT, effectively producing native code alongside the MSIL) used for the framework you gain a lot of performance. AOT is sort of there for user apps as well, depending on what you need to do.

The JIT compiler itself has a phenomenal amount of optimisations to produce better performing machine code, plus the ability to reoptimise the compiled code as it learns more about the usage patterns. This also doesn't take into account that the JIT and the Framework can leverage processer extensions such as AVX etc. to obtain even better performance.

If you want some real detail on performance then https://devblogs.microsoft.com/dotne...ents_in_net_7/ is a really detailed blog on the topic, https://aka.ms/net7-perf-pdf is the same as a PDF which might be a bit easier to read....

Quote:

---

Originally Posted by The trick

WOW64 layer is actual for API calls. I'm talking about processor instructions which are quite faster than x86-instructions. VB6 can't compile 64 bit binaries like .NET does. So .NET has the speed advantages due to x64-84 instruction set. Today i think few machines have 32-bit windows.

---

Right it's a different instruction set on hardware... That's why it's not fair to compare 32bit VB to 64bit .NET. To know whether the performance is the instruction set or the higher level code, one should compare VB6 to 32bit .NET. Or 64bit twinBASIC to 64bit .NET

Quote:

---

Originally Posted by PlausiblyDamp

If you want some real detail on performance then https://devblogs.microsoft.com/dotne...ents_in_net_7/ is a really detailed blog on the topic, https://aka.ms/net7-perf-pdf is the same as a PDF which might be a bit easier to read....

---

Very interesting! thanks!

Wanted to get back to this thread for a while. Was busy with some real life stuff.

Quote:

---

Originally Posted by taishan

Niya, I didn't make myself clear, and I don't want to dis the choice of your programming language. I wasn't implying .NET had anything to do with P-Code. I didn't use VB5 because of P-Code. I still used QuickBasic, Pascal, or Delphi.

---

I was taking issue with the fact that your statement implies that .Net is slower than VB6 which is quite wrong. I get that you don't like .Net and that's fine but claims of .Net being slower because of it's framework or it's bytecode is just flat out wrong. That's all I was trying to point out.

Quote:

---

Originally Posted by The trick

Actually x64 gives the quite performace boost so .NET exectuables will give the better performance i guess. Moreover .NET execuatebles have JIT compiler which makes the native code so the performance degrade should be only for the first run i guess. I'm not a .NET expert and i can be wrong.

---

I've observed this to be the case in a few instances.

Quote:

---

Originally Posted by fafalone

I don't suppose you have numbers to back up this attitude... I'd bet that you have to go very far out of your way in .NET to match VB6, rather than the other way around. If you went out of your way in VB6, into the techniques on vbspeed and asm thunks, spanning and whatever else you want to do in .NET isn't coming within a gigaparsec of VB6.

---

This isn't even close to being true. Let's just at a classic favorite for benchmarking, summing vectors:-

Code:

---

Public Sub VectorSum(ByRef v1() As Long, ByRef v2() As Long, ByRef result() As Long)
    Dim i As Long

    For i = 0 To UBound(v1)
        result(i) = v1(i) + v2(i)
    Next i
End Sub

---

That is a very naïve implementation of a function that sums two equal size vectors and writes the result to a 3rd vector. When I compile this with all optimizations enabled and execute it to add two Long vectors with 300 elements it takes around 1300 nanoseconds to complete.

Now before I get to how .Net performs I just want to introduce the concept of a cold start. The .Net has runtime environment has a number of non-deterministic algorithms running in the background that tunes the way a .Net application runs. This includes the GC and JIT. This tends to negatively affect performance at the start-up of a .Net application. However, it quickly stabilizes into a stead state.

Here is a C# version of the same vector summing function:-

Code:

---

    public static void VectorSum(int[] v1, int[] v2, int[] result)
    {
        for (int i = 0; i < v1.Length; i++)
            result[i] = v1[i] + v2[i];

    }

---

With a 32 bit debug build cold start this takes around 1500 nanoseconds which is in the vicinity of the fully optimized VB6 version. With a 32 bit release build cold start, it takes about 700 nanoseconds which is about twice as fast. A 64 bit release build cold start took about 400 nanoseconds which is in the vicinity of 4x faster than the slowest times measure so far.

Using BenchmarkDotNet, I was able to measure it's actual performance unaffected by the noise of a cold start. Compiled as 64 bit release build and executed when the environment is stable it took around 160 nanoseconds.

So to recap:-

VB6 fully optimized release build	1600 ns
.Net 32 and 64 bit cold start debug build	1600 ns
.Net 32 bit cold start release build	700 ns
.Net 64 bit cold start release build	400 ns
.Net 64 bit "warm run" release build	160 ns

Just for fun I decided to throw in a C# Avx2 version of the vector sum function:-

Code:

---

public unsafe static void VectorSumAvx(int[] v1, int[] v2, int[] result)
    {

        if (!Avx2.IsSupported) throw new Exception("Avx2 is not supported on this device.");

        Vector256<int> vec1;
        Vector256<int> vec2;

        //Make sure the lenth is evenly divisible by 8
        int len = (v1.Length / 8) * 8;
        int remainders = v1.Length % 8;


        fixed (int* pv1 = v1, pv2 = v2, pvrec = result)
        {

            // Might as well be writing x86 assembly here.
            // This code copies array values into the YMM registers
            // 8 at a time, adds them and write the sums back
            // to memory in the result array
            for (int i = 0; i < len; i+=8)
            {
                // Load 8 integers from each array
                // into YMM registers
                vec1 = Avx2.LoadVector256(pv1 + i);
                vec2 = Avx2.LoadVector256(pv2 + i);

                // Add all 8 pairs of integers in YMM registers
                // simluntaneously using the VPADDD x86 instruction from
                // the AVX2 subset of SIMD instructions.
                var r = Avx2.Add(vec1, vec2);

                // Write the result of the additions
                // back to memory.
                Avx2.Store(pvrec + i, r);
            }

        }

        // Handle remainders normally.
        for (int i = len, x = 0; x < remainders; i++, x++)
        {
            result[i] = v1[i] + v2[i];
        }

    }

---

A 64 bit release build warm run of the above takes 37 nanoseconds, that a little more than 4x faster than the previous fastest speed and around 43x faster than a non-vectorized version executing in a fully optimized VB6 release build!

The .Net compiler I used for all these tests is from .Net 6 by the way, which might as well be a dinosaur. We are already on .Net 8 now. .Net 6 is outdated tech.

So what does this all mean? It means that .Net is fast, very very fast.

Now again, to be clear, this isn't to say that it's not possible to achieve a performance of 37 nanoseconds in VB6. I'm 100% certain you guys are more than talented enough to achieve it. My point is to dispel this persistent myth that .Net is a slow platform. The only real advantage VB6 developers have in terms of raw performance is that they don't have to content with cold starts. Outside of that very narrow scenario, .Net is blazing fast.

One more thing, I'm not a benchmarking expert, especially not with VB6 so I could have screwed up somewhere measuring in VB6. I'll post the full VB6 code in the next post, maybe you guys can tell me if I screwed something up that made this test unfair.

Here is the full VB6 code I used for benchmarking in VB6. Please tell me if I got anything wrong or suggest a better way to benchmark if you can:-

Code:

---

Private Declare Function QueryPerformanceCounter Lib "kernel32" ( _
    lpPerformanceCount As Currency) As Long

Private Declare Function QueryPerformanceFrequency Lib "kernel32" ( _
    lpFrequency As Currency) As Long

Private Declare Sub Sleep Lib "kernel32" ( _
    ByVal dwMilliseconds As Long)

Private Sub Form_Load()
    DoTest
End Sub

Private Sub DoTest()
    Const COUNT As Long = 300
    Dim vecA() As Long
    Dim vecB() As Long
    Dim vecResult(0 To COUNT - 1) As Long
    Dim t As Currency
           
    Text1.Text = ""
       
    vecA = GenerateIntArray(COUNT)
    vecB = GenerateIntArray(COUNT)
   
    t = GetTimeStamp()
    VectorSum vecA, vecB, vecResult
    t = GetTimeStamp() - t
   
    Prn "VectorSum : " & FormatTime(t)
 
   
End Sub

Public Sub VectorSum(ByRef v1() As Long, ByRef v2() As Long, ByRef result() As Long)
    Dim i As Long

    For i = 0 To UBound(v1)
        result(i) = v1(i) + v2(i)
    Next i
End Sub


Public Function GenerateIntArray(ByVal n As Long) As Long()
    Dim i As Integer
    Dim intArray() As Long
   
    ReDim intArray(0 To n - 1) As Long
   
    Randomize
    For i = 0 To n - 1
        intArray(i) = CLng(Int((10 * Rnd) + 1))
    Next i
 
   
    GenerateIntArray = intArray
End Function

Public Function GetTimeStamp() As Currency
    QueryPerformanceCounter GetTimeStamp
End Function

Private Function FormatTime(ByVal ticks As Currency) As String
   
    Dim c As Double
    Dim freq As Currency
   
    'Let freq = ticks per second
    QueryPerformanceFrequency freq
   
    'We want to measure in nanoseconds
    c = ticks * 10 ^ 9
   
    FormatTime = CStr(c / freq) & " ns"
End Function

Private Sub Prn(ByVal s As String)
    Debug.Print s
    Text1.Text = Text1.Text & s & vbCrLf
End Sub

---

If I could do anything useful measured in nanoseconds I would be very happy - and I interject this thread with my usual garbage just to remind people how thoroughly hijacked this thread has now become (with Niya up to his old VB6vs VB.NET sidetracking/hijacking tricks).

Get yourself a room, start a chat there and stick with it.

If you pollute other threads with the same old chat each thread each ultimately becomes worthless as a technical resource.

I'm going to ask the mods to close this one (not mine I know) just to prevent more pollution.

One other thing before I forget:-

Quote:

---

Originally Posted by fafalone

You're really overstating the levels of abstraction in VB6 and understating it in .NET.

---

No I'm not. The C# compiler in particular is very low level. Going back to the Avx function I posted earlier:-

Code:

---

public unsafe static void VectorSumAvx(int[] v1, int[] v2, int[] result)
    {

        if (!Avx2.IsSupported) throw new Exception("Avx2 is not supported on this device.");

        Vector256<int> vec1;
        Vector256<int> vec2;

        //Make sure the lenth is evenly divisible by 8
        int len = (v1.Length / 8) * 8;
        int remainders = v1.Length % 8;


        fixed (int* pv1 = v1, pv2 = v2, pvrec = result)
        {

            // Might as well be writing x86 assembly here.
            // This code copies array values into the YMM registers
            // 8 at a time, adds them and write the sums back
            // to memory in the result array
            for (int i = 0; i < len; i+=8)
            {
                // Load 8 integers from each array
                // into YMM registers
                vec1 = Avx2.LoadVector256(pv1 + i);
                vec2 = Avx2.LoadVector256(pv2 + i);

                // Add all 8 pairs of integers in YMM registers
                // simluntaneously using the VPADDD x86 instruction from
                // the AVX2 subset of SIMD instructions.
                var r = Avx2.Add(vec1, vec2);

                // Write the result of the additions
                // back to memory.
                Avx2.Store(pvrec + i, r);
            }

        }

        // Handle remainders normally.
        for (int i = len, x = 0; x < remainders; i++, x++)
        {
            result[i] = v1[i] + v2[i];
        }

    }

---

Pay particular attention to what that code is doing. It's using pointers to load the vector registers. This is a lower level of abstraction than VB6 as you would need functions like VarPtr and RtlMoveMemory. In contrast, the C# compiler is capable of handling it directly without the overhead of function calls.

Quote:

---

Originally Posted by yereverluvinuncleber

If I could do anything useful measured in nanoseconds I would be very happy - and I interject this thread with my usual garbage just to remind people how thoroughly hijacked this thread has now become (with Niya up to his old VB6vs VB.NET sidetracking/hijacking tricks).

Get yourself a room, start a chat there and stick with it.

If you pollute other threads with the same old chat each thread each ultimately becomes worthless as a technical resource.

I'm going to ask the mods to close this one (not mine I know) just to prevent more pollution.

---

Fafalone asked a question, I answered. No need to get cross.

No, I am not cross! Not at all - possibly, however, a little pedantic. Call me old fashioned but I just like the interesting threads in this forum to have the content as determined by the OP.

Niya, I find your contributions interesting and enlightening. I just don't like to find vb6 vs VB.NET posts here, there and everywhere filed under such unrelated threads as "how to fix a washing machine" - as they aren't really relevant to the main thread.

We all know how these vb6 vs VB.NET posts go. Perhaps create a new thread and link across? I'd avidly read them if done that way.

I though about making a new thread but decided against it. I just wanted to answer fafalone's question and opening a new thread on this will invite all kinds of VB6 vs VB.Net chaos all over again. Such a discussion is far too subjective to reach any kind of resolution and besides, I've said all I can say on that topic already. It was easier just to answer the question in this thread and be done with it.

If he or you are actually pursuing further discussion on VB6 vs .Net performance in another thread, I'm willing to have it but you guys have to state that explicitly. If I start such a thread it's just going to be mayhem.

Quote:

---

Originally Posted by Niya

The .Net compiler I used for all these tests is from .Net 6 by the way, which might as well be a dinosaur. We are already on .Net 8 now. .Net 6 is outdated tech.

So what does this all mean? It means that .Net is fast, very very fast.

---

Just a quick one... .Net 7 special cases certain Linq operations, doing a .Sum or .Average over integers or longs utilises hardware intrinsics automatically. It even figures out the best available depending on the CPU architecture.

If the OP would like it closed, I'll close it. Otherwise I won't at this time. I do think that this has gotten pretty well side tracked, but it's gotten side tracked into the patch of weeds where a whole lot of programmers like to reside: Performance optimization. The discussion has been quite straightforward and non-confrontational, so while it is not on topic, I'd also call it educational, and that's a reasonable point behind the thread in general.

Of course, .NET vs VB6 certainly does have a long track record of getting messy, but fortunately that has not happened in a time.

Quote:

---

Originally Posted by PlausiblyDamp

Just a quick one... .Net 7 special cases certain Linq operations, doing a .Sum or .Average over integers or longs utilises hardware intrinsics automatically. It even figures out the best available depending on the CPU architecture.

---

Wow. That is simply amazing. It's about time they did that.

This reminds me, I was sent a video on performance enhancements in the latest .Net iterations. I need to finish watching that video. Perhaps it was mentioned there.

Quote:

---

Originally Posted by Shaggy Hiker

but fortunately that has not happened in a time.

---

Well let's hope it stays that way. I specifically avoided any temptation to suggest that .Net is better or that it should be chosen over VB6. My opinions on this matter haven't changed. However, I've learned to recognize that perhaps even among Windows programmers everyone's needs don't necessarily overlap as much as I would like to believe. The people that have chosen to stick with VB6 might have good reasons to do so. As such, I try to stick with just facts and avoid straying into subjective discussions. Performance discussions are about as objective as it gets. It about hard facts so I see very little to fight about....hopefully ;)

Quote:

---

Originally Posted by yereverluvinuncleber

If I could do anything useful measured in nanoseconds I would be very happy...

---

Forgot to touch on this too. I'm quite surprise at your attitude here given your interest in deeper matters when it comes to programming. I didn't choose to measure in nanoseconds here for some arbitrary reason. This was very deliberate. Now as I said, I'm no benchmarking expert but I've learned a thing or two about the subject.

I'm trying here to measure the performance of compilers or more specifically, the code they produce. It's important not to fall into common traps. I chose vector summing algorithms for my tests which unavoidably involves memory access. A common pitfall in benchmarking scenarios is failing to account for overheads which can skewer results. In this particular case, memory accesses can seriously bottleneck performance. If I chose to sum say, a pair of vectors 10 million elements in size, then the vast majority of the time would actually be spent accessing memory, not actually performing the calculations. I don't want to measure how fast Windows handles memory. I want to measure the overall performance of summing vectors. I needed to choose a vector size suitable enough that the performance isn't dominated by memory reads and writes.

I chose a 300 element vector pair as a decent compromise. However, because of the small size here, the operation happens way too fast to measure in milliseconds using something like Timer. I needed to measure using a high resolution timer which is why I opted to use QueryPerformanceCounter to measure in nanoseconds.

Also, I should say that a lot of benchmarking in our field happens in the microsecond and nanosecond ranges specifically to lessen the impact of things like memory access on measurements. This is one of the reasons why functions like QueryPerformanceCounter exist.

What he wanted to say is that shaving a few nanoseconds here and there is irrelevant. When code optimizations start to go into the realm of seconds that's where you can say a compiler is better than another. But a compiler can't do that, only humans can by programming more efficiently and then the compiler doesn't matter.

Quote:

---

Originally Posted by The trick

Today i think few machines have 32-bit windows.

---

Most of the machines, where this is critical, are old machines running old things. In a consumer-market, there are not may 32-bit systems left. In a commercial-market, there are billions of 32-bit machines still running. Even 16-bit ones and lower.

I'll use an example...

"Hallmark Cards" still uses old 8-bit/16-bit hardware to run everything from conveyor-sorting to the robot-lifts that store and extract pallets of product in the warehouse. In the office, they are still using "Windows NT 3.1", "Windows 98se" and "Windows XP sp3". All due to the "rights" they purchased. (Contrary to popular belief, windows still does provide "support" for those computers, with those licenses. I'd watch the techs, with microsoft uniforms and IDs, come in, almost daily, to "support" the products. :P ) At one time, it was well over 3000+ computers. I'm not sure there is that many still in use today. They close the offices where I lived.

I think the issue for the "machines", was that they all demanded "real" physical "printer ports". Not "emulated printer-ports". LPT1 and LPT2, for talking to the controller-boards and sensors. The issue with the software, was... Millions was spent making this stuff, using "top of the line" software, at the time. A price they refused to pay again, for upgrading and in losses, due to failed upgrade attempts, from newer systems.

They also still use "tape drive backups", from 1985, for all records. (Giant towers with a single tape-real in each unit. I saw over 12 of these beasts running, and ONE single, cheap SSD, would replace all of them today. But the ancient systems they refuse to update, can not talk to anything other than the tape-drives.)

I was burdened with using one of these older systems (98se), when "Windows XP sp3" was out. I had to do 3D artwork for them. The whole job took over a year to do, what I could have done in a week, with my own laptop that they REFUSED to allow me to use. Because they wanted to "monitor my files on the network". (Which, by the way, I ended-up crashing, due to my HUGE raw image files needed for rendering a 4'x6' poster at 150DPI. I literally stopped them cold, for two days. It filled every tape-drive up, and was hung-up trying to save the last file that it couldn't fit. I gave them fair warning not to back-up my files! Fun times!)

Similar situation in a "Plastic Injection Molding Plant" that I worked at. The visual cameras and "workload planners", still operate on "Windows 95c". (They only had "C" due to the need for USB support! That was how we setup profiles and transferred settings to the machines to use.)

P.S. You won't see any of these beasts listed on "Website hardware use", because 99% of these machines are not even allowed to talk to the Internet. Some barely use "Intranets" internally. Hallmark Cards looked like a rats-nest of physical wires in the rafters. Every computer was hard-wired to the server room and there was only ONE gateway to a physical connection, directly to "Kansas City Distribution", (from the Connecticut offices). That connection was rated in bauds still, and it wasn't 56Kbps. Maybe, at best, 14.4Kbps, upgraded from the original 2600 bauds connection. That was a DIRECT phone-line, not even over the public phone-lines. They were THAT paranoid about "cards". :P

Quote:

---

Originally Posted by VanGoghGaming

What he wanted to say is that shaving a few nanoseconds here and there is irrelevant. When code optimizations start to go into the realm of seconds that's where you can say a compiler is better than another. But a compiler can't do that, only humans can by programming more efficiently and then the compiler doesn't matter.

---

I know but this is an extremely naïve and simplistic view on matters of performance. I'm measuring vector addition which involves the use of arrays. In order to understand the performance of the operation it is essential to measure in the microsecond/nanosecond range because any higher than that, and you stop measuring vector addition and start measuring memory access. This kind of mistake can lead one to draw the wrong conclusion about the performance of a particular piece of code.

Look at this for a minute:-
https://www.vbforums.com/images/ieimages/2023/03/18.png

Here I'm comparing the performance of both the SIMD and non-SIMD versions of the vector summing algorithms with various vector sizes. So what does it say? Well that table gives me important information which I can use to make important decisions.

• From that chart I know if if I have to sum vectors with a handful of elements, it's probably best to use a simple implementation. SIMD doesn't give much benefit in this scenario.
  
  
• It also tells me that if need to sums vectors in the range of 100 to couple thousand elements, then I can greatly benefit from SIMD as it gives a 3x to 6x boost in performance for vectors of these sizes.
  
  
• Vector sizes in the range of the tens of thousands seem to be the upper limit of where SIMD can offer performance boosts as it went from giving a 6x boost to a nearly a 3x boost.
  
  
• Finally, it also tells me that when in the range a million elements or more, memory access starts becoming a problem so if I ever need to sum vectors of this size, I need to consider a completely different strategy.
  

You cannot just disregard micro-measurements just because "it's only a few nanoseconds that wouldn't make a difference". These kinds of measurements can provide a much clearer picture of the performance characteristics of an algorithm which can lead you to make better decisions.

As for how this plays into comparing different compilers, the table gives me a lot of important information that I could use to make decisions here. It tells me that with extremely small vector sizes of a few dozen elements that I cannot get away with such a naïve implementation of vector summing in VB6 as it clocks in around 600 ns which is about 100x slower than in .Net. A 100x difference is nothing to scoff at. If you have an algorithm that spends a lot of it's time summing small vectors that remain fixed in memory, you're going to feel that 100x difference so you need to be aware of it which can only happen if you're willing to perform micro-benchmarks like this in the nanosecond range.

The table also tells me that vector sizes upward of a million elements, the compiler doesn't matter as the bottleneck is memory performance which is more about your hardware and the Windows operating system itself.

@niya - not had chance to try this but I wonder if using a Span<int> instead of pointers would make any difference to performance.

How’s the Bench marks for ide debug session startup to form display.

During dev I have stop start debug sessions approximately 3578421679864226789 times
That’s probably the most meaningful benchmark to me anyway. Java used to kill me