[RESOLVED] Same Code Compiled on windows 11 will not run on Windows 7

Hello group

I am forced to move to Windows 11 for development

when i compile the exact code base on win 11 and move exe to win7 I get this error:

Run Time Error '430';
Class does not support Automation or does not support expected interface

I looked at the .vpb file and it does appear one of the references changed in my .vpb on win 11 to winhttpcom.dll from winhttp.dll

Does anyone have insight on this issue?

I only use windows 7 for this purpose.
I know that my compiled-exe works in windows 7 and beyond.
but if I compile my project in a windows 10 computer. the exe will behave oddly, sometimes crash, something gives strange values. its a mess.
so until I know all people have abandoned windows 7, I will not move to 10/11.
maybe TwinBasic will not behave like this, we will see.

After a bit more forensics it appears it is related to a LoadPicture call.

It appears that every call to loadpicture is causing this, maybe related to te iPictureDisp interface?

It also looks like it occurs when I unload control array elements

The type library was moved after Windows 7, but that only gets used at design time.

Since this is a system library, compiled programs should be finding the compiled code to use through the registry (vis ClsId, or ProgId if you using using old script code).

Sounds like a deployment error.

I have no idea why any other language wouldn't work the same. If anything, RandoBasic is likely to give you more trouble by not knowing how to properly update references.

Windows 7 is beyond dead at this point, and has never been a viable development platform due to its numerous compatibility breaks.

Quote:

---

Originally Posted by dilettante

The type library was moved after Windows 7, but that only gets used at design time.

Since this is a system library, compiled programs should be finding the compiled code to use through the registry (vis ClsId, or ProgId if you using using old script code).

Sounds like a deployment error.

I have no idea why any other language wouldn't work the same. If anything, RandoBasic is likely to give you more trouble by not knowing how to properly update references.

Windows 7 is beyond dead at this point, and has never been a viable development platform due to its numerous compatibility breaks.

---

Sorry for the ignorance...

can you explain in more simple terms?

are you saying becuase of the updated OS core dll's a exe compiled in vb6 on win 11 cannot work in win7?

Windows 7 had a lot of those problems, mostly because of type libraries Microsoft changed when they tried to make 64-bit Office work. These got fixed later, but Windows 7 had already left mainstream support so it never got automatic updates for those problems.

If you hunt around some of them did get fixes later on for Win7 SP1 but these had to be tracked down, downloaded, and installed manually.

Most of those were related to Common Controls and WDAC 6.1 though. WinHTTP did not need any fixes, the type library didn't change but only moved to another file after Windows 7.


I just tested a program that I compiled on Windows 7 using WinHTTP. It runs perfectly well on Windows 11, but when trying to open the VBP (Project) on Windows 11 it gets an error due to the use of one of the Common Controls OCXs.

This was one of the things that Windows 7 broke. The same Project saved on a Vista system still opens just fine on Windows 11. Windows 7 was a mess for development and caused lots of these problems.

I tested the windows 11 compiled app in windows 10 and got the same error.

so the same source compiled on win7 works in 7,10 , and 11

the one compiled on win11 onyl works on win11 and not on 10 or 7

Well, I am now thinking it is related to : stdole2.tlb

Unfortunately I have no wisdom here, but my guess is this gets compiled into the exe and the updated tlb in win11 is not compatible with win7 or 10?

so the question is, can this be resolved?

Im a game programmer and the project I have has 0 components added. the project is huge, result in 1.2MB in size for the EXE (and remember I use a compiler-tool, so the exe is quite empty, everything run dynamically, like string-table and other variables are loaded in, same with all pictures)
I have 1 form and 1 picturebox and reference to direct2d/directsound and a few other API.

when I compile the exe in windows 7 and I run it. it works without issues. if I run it in 8,10,11 it works well. no issues.
when I compile the exe in windows 10 and I run it. it gives me issues sometimes. theres kind of glitches. incorrect values, strange crashes etc. people report tons of "new" bugs. strange bugs that are impossible to fix. and know this, I have tried. for some time I compiled it in windows 10. it was hell. (I mean, its not that it gives the same bug all the time. its almost random and not all the time)

so, I think theres a problem with the "core" stuff.
maybe what axisdj wrote stdole2.tlb or maybe another tlb that is needed to compile the EXE.

to get help from dilettante is impossible he will only say: its your own fault. you are a bad programmer, U did something wrong here. or move on loser, windows 7 is not used. what are u doing? get a life etc. he is the master of "Grumpy Old Men".

I mean, he doesn't give a crap about your needs. as I have mentioned in many many thread. PEOPLE ARE STILL USING WINDOWS 7. I get my game downloaded by 10000+ and not everyone are like dilettante and is using windows 11.

so, I don't dare move to windows 10/11, because I dont want to spend all my time trying to fix bugs are should not be there. no matter how much I look into the code, it doesn't make sense.
its like the EXE is corrupted, injected with a virus or something oddly. (of course not, but the EXE is bad)

OF COURSE, before dilettante start to argue. if I compile a 10 lines code it will work.
this happens in complex and big projects. and its "random", so it could work 9 out of 10 times, but without warnings and sense, a bug happens.
and NO, before dilettante start to argue. the code works PERFECTLY if compiled in windows 7.

so googling around, here someone reported an issue with OS compatibility
https://stackoverflow.com/questions/...ons-of-windows

this is interesting reply:

Quote:

---

That is a very different issue. If office 2016 not supported on windows 8.1, then you better continue to develop to the lowest common system.

---

that is exactly what Im doing. using the lowest system to make it compatible.
now they talk about office/access. but also OS differences and versions incompatibility,
and

Quote:

---

It's not just Windows 8.1 because I have a client running Windows 10 and my access 2010 runtime which causes the same problem and is the reason for this Question. –

---

and this is exactly my point. it causes issues "everywhere".
but surely dilettante will say. its your own fault. u are a bad programmer. move to windows 10, don't use windows 7. etc etc etc.

Windows 7 only became slightly less used than Windows 11 a couple months ago, not what I would call dead. And I expect the share among those using VB6 apps to be substantially higher.

It looks like the error you are experiencing is related to a problem with a missing or incompatible reference in your Visual Basic project. The message "Class does not support Automation or does not support expected interface" usually indicates that a class or object in your code is trying to use a method or property that is not supported by the version of the reference you are using.

The fact that the reference to winhttpcom.dll changed from winhttp.dll when you moved your code from Windows 7 to Windows 11 suggests that the issue may be related to differences in the versions of these libraries between the two operating systems.

One possible solution to this problem would be to try using the same version of winhttpcom.dll or winhttp.dll on both operating systems. You can try searching for and downloading the appropriate version of the library and then adding it to your project as a reference.

Alternatively, you may be able to fix the problem by updating your code to use a different method or property that is supported by both versions of the library. This may require some research and testing to determine the best approach.

I hope this helps!

Do you have VBPNG installed?

Quote:

---

Originally Posted by dilettante

Windows 7 had a lot of those problems, mostly because of type libraries Microsoft changed when they tried to make 64-bit Office work. These got fixed later, but Windows 7 had already left mainstream support so it never got automatic updates for those problems.

If you hunt around some of them did get fixes later on for Win7 SP1 but these had to be tracked down, downloaded, and installed manually.

Most of those were related to Common Controls and WDAC 6.1 though. WinHTTP did not need any fixes, the type library didn't change but only moved to another file after Windows 7.


I just tested a program that I compiled on Windows 7 using WinHTTP. It runs perfectly well on Windows 11, but when trying to open the VBP (Project) on Windows 11 it gets an error due to the use of one of the Common Controls OCXs.

This was one of the things that Windows 7 broke. The same Project saved on a Vista system still opens just fine on Windows 11. Windows 7 was a mess for development and caused lots of these problems.

---

the Os compatibility argument does not really apply here as the app compiled in win11 does not work on win10

I hope someone out there could give us some new perspective

I do not

Quote:

---

Originally Posted by The trick

Do you have VBPNG installed?

---

I do not..

I assume you may have seen this issue as well by the context of your question?

I do not understand compilers, but one guess I have is that a newer stdole2.tlb is getting compiled into the vb6 app when compiled on windows 11, and that new file does not work in windows 7. I did try to replace stdole2.tlb on my win11 machine but the OS will not allow it. As loadpicture is declared in stdole2 and that is one of the scenarios that causes the error (failure to load app) my guess is that something changed

the question is can this be resolved.

I did manage to find a post where loadpicture is called like this stdole.stdcalls.LoadPicture and intellisense shows different arguaments, not sure if I change the code to that if it will resolve, will try tomorrow as I am not back in office until then.

so got a response from TB about this,

Quote:

---

Originally Posted by WaynePhillipsEA

provided the type libraries you're compiling against are the same, then tB will generate the same binary regardless of OS. If you've got a problem with a particular type library being different on different OS, then tB allows you to 'Import' a type library. With the Import feature, the typelibrary is imported directly into the project filesystem and so tB doesn't lookup the typelibrary via the system registry. This means, for example, you can compile against an older type library despite having a newer one registered on your development machine.

---

so, the question is, can we do the same with VB6 as well?
some "hacks" to be strict about what TLB to be used when compiled?

Quote:

---

Originally Posted by baka

so got a response from TB about this,



so, the question is, can we do the same with VB6 as well?
some "hacks" to be strict about what TLB to be used when compiled?

---

I could not find a way, windows 11 did no allow it changing out stdole2.tlb, neither did vb6 ide References via browse.

I would be curious if anyone here had had success with compiling in win11 and testing the exe on win10 or win7 (using loadpicture in code)?

Please attach your tlb.

Quote:

---

Originally Posted by The trick

Please attach your tlb.

---

Will do tomorrow, unfortunatly not in office that has win11 pc today.

I will post both first thing in the morning. Can I ask if you have any initial thoughts?

This is a far-fetched theory that TLBs with same GUID are different on Win7 vs Win11. You can always binary compare stdole2.tlb or decompile it and compare sources.

Actually this is what I did here: stdole2.tlb decompiled from Win7 altered by the changes done in Win11

They *do* differ in a way that *could* lead to incompatibilities which is bizarre, hmmm. . .

@The Trick: Your thoughts?

If I compile a callsite to LoadPicture on Win11 and run it on Win7 but the export is not named OleLoadPictureFileEx (available only by ordinal 0x60000000) this could fail.

There is OleLoadPictureFileEx exported at ordinal 0x60000000 on Win7 so disater averted but still this is very unprovoked fix which I hope they tested well in Win7, XP and downwards.

cheers,
</wqw>

wqweto i don't have Win11 to check (compile an exe and run in a previous version of Windows). Regarding to the error i suppose it's related to IPicture/IPictureDisp interface.

Quote:

---

Originally Posted by baka

to get help from dilettante is impossible he will only say: its your own fault. you are a bad programmer, U did something wrong here. or move on loser, windows 7 is not used. what are u doing? get a life etc. he is the master of "Grumpy Old Men".

I mean, he doesn't give a crap about your needs. as I have mentioned in many many thread. PEOPLE ARE STILL USING WINDOWS 7. I get my game downloaded by 10000+ and not everyone are like dilettante and is using windows 11.

---

This made me chuckle a bit too much. I mean you're not wrong, just don't get into an argument with the guy. I admit I've shamelessly copied and modified snippets of his code and used them for my purposes a number of times throughout the years. Whenever I google for something exotic and VB6 related I inevitably stumble upon his posts (along with a few others form this forum to be fair). I'm sure he must have spent countless hours wading through poorly written and sparse documentation for some obscure functions or classes and then post a working example for everyone to use. That is something to be commended for sure.

Anyway, what I really wanted to ask you was about your VB6 game that is downloaded by tens of thousands! I'm really curious to see what is it about, maybe you have a Youtube video showcasing it?

In my opinion, VB6 has always been a lazy man's tool (and there's nothing wrong with that)! Just because you CAN do almost everything in VB6 doesn't mean you always should. But that is a discussion for another topic (or another forum altogether)! :D

None of the VB6 tool chain ships as part of Windows. You have to install the compiler, the linker, basically everything.

I just compiled 10 VB6 programs on Windows 11, copied the compiled EXEs to a Windows 10 machine, and all of them run perfectly.

Clearly what is going on above is some combination of improperly installed and updated VB6 and old Projects contaminated by being worked on under Windows 7, which has been known known to be problematic for a very long time. Contaminated Projects can be repaired, but you have to correct their type library references by hand.

There are three parts to these: a GUID, a type library version, and a locale ID (typically just a 0).

Quote:

---

Originally Posted by dilettante

None of the VB6 tool chain ships as part of Windows. You have to install the compiler, the linker, basically everything.

I just compiled 10 VB6 programs on Windows 11, copied the compiled EXEs to a Windows 10 machine, and all of them run perfectly.

Clearly what is going on above is some combination of improperly installed and updated VB6 and old Projects contaminated by being worked on under Windows 7, which has been known known to be problematic for a very long time. Contaminated Projects can be repaired, but you have to correct their type library references by hand.

There are three parts to these: a GUID, a type library version, and a locale ID (typically just a 0).

---

Hello,

do you use LoadPicture() in those programs?

That is good news that you are able to compile on 11 and run on 10, that gives me hope it is just my setup.

I will run more test tomorrow and report here

btw I installed vb6 enterprise and SP6

Code:

---

Option Explicit

Private Sub Form_Load()
    Set Picture = LoadPicture("SomePic.gif")
End Sub

---

Compiled on Windows 11. Runs fine there. Copied EXE and GIF to Windows 10, runs fine there.

as I wrote, I use Direct2D, WIC, OLEEXP and DirectSound for my game. those typelibs are the same.
the other references are:

Visual Basic For Applications (that should be the same)
Visual Basic runtime objects and procedures (that is located in C:\Windows\sysWOW64, that could be a problem)
Visual Basic objects and procedures (that should be the same)
OLE Automation (that is different C:\Windows\sysWOW64\stdole2.tlb)

the last one I can be without, but if I want to use API like OleCreatePictureIndirect, I need to include it. its the IPicture/StdPicture reference.

but the issues I get are not related to this at all.
the game itself its buggy. resulting in glitches. like some "memory" issue. maybe related to msvbvm60?
since the values of the game gets altered and of course if messing with values too much, eventually it will crash.
if I compile in windows 7, the game works well in all OS, but compiling it in windows 10 result in this.
and theres no "error" code showing like axisdj has. its full crash. or full glitches.

so, lets assume theres some "odd" memory leaks that will show in "big projects" or "specific project"
it will work, but since theres a memory problem, eventually it will start causing issues. strange behavior. and sometimes crashes.

dilettante just compile a couple of projects, make a run and if its works = ITS WORKING, SEE?!? I KNOW EVERYTHING U ARE ALL WRONG.
but u need to do A LOT OF TESTING. since it require the memory to be used "A LOT". u can not just test-run it. it need to run for a long time and u need to have a project that require MANY things.
my game is that. doing A LOT OF CALCULATIONS.

so, sure, following dilettante's conclusion. IT WORKS. well. it do until it doesn't. what then?
my game require it to be 100% correct. I can not have values altered. people will complain if they lose money, or their character gets faulty health values, or one item disappear or get bad.
or when saving, the save-data is corrupted and he can not load it anymore. I mean.... I CAN NOT HAVE IT LIKE THAT.

its not a utility tool that do a couple of calculation and some text-editing.
for u it WILL NOT MATTER. it works. and probably it will always even if sometimes something odd happens. but its not the end of the world.

but, the problem is, THERES SOMETHING GOING ON. and it can affect everybody.

dilettante: I compiled the simple loadpicture sample you tested on win11, and it ran fine on win7 so it appears loadpicture on a single line app does not have an issue.

trick: I am attaching the stdole2 file traits

here are my reference entries in vpb

Windows11

Code:

---

Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Reference=*\G{6B263850-900B-11D0-9484-00A0C91110ED}#1.0#0#C:\Windows\SysWow64\msstdfmt.dll#Microsoft Data Formatting Object Library 6.0 (SP6)
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#C:\Windows\SysWOW64\scrrun.dll#Microsoft Scripting Runtime
Reference=*\G{662901FC-6951-4854-9EB2-D9A2570F2B2E}#5.1#0#C:\Windows\system32\winhttpcom.dll#Microsoft WinHTTP Services, version 5.1
Reference=*\G{00000205-0000-0010-8000-00AA006D2EA4}#2.5#0#C:\Program Files (x86)\Common Files\System\ado\msado25.tlb#Microsoft ActiveX Data Objects 2.0 Library
Object={6BF52A50-394A-11D3-B153-00C04F79FAA6}#1.0#0; wmp.dll
Reference=*\G{7C0FFAB0-CD84-11D0-949A-00A0C91110ED}#1.0#0#C:\Windows\SysWOW64\msdatsrc.tlb#Microsoft Data Source Interfaces for ActiveX Data Binding Type Library
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll

---

Windows7

Code:

---

Reference=*\G{6B263850-900B-11D0-9484-00A0C91110ED}#1.0#0#..\..\..\..\Windows\SysWow64\MSSTDFMT.DLL#Microsoft Data Formatting Object Library 6.0 (SP6)
Reference=*\G{420B2830-E718-11CF-893D-00A0C9054228}#1.0#0#..\..\..\..\Windows\SysWOW64\scrrun.dll#Microsoft Scripting Runtime
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\Windows\SysWOW64\stdole2.tlb#OLE Automation
Reference=*\G{662901FC-6951-4854-9EB2-D9A2570F2B2E}#5.1#0#..\..\..\..\Windows\system32\winhttp.dll#Microsoft WinHTTP Services, version 5.1
Reference=*\G{00000205-0000-0010-8000-00AA006D2EA4}#2.5#0#..\..\..\..\Program Files (x86)\Common Files\System\ado\msado25.tlb#Microsoft ActiveX Data Objects 2.0 Library
Object={6BF52A50-394A-11D3-B153-00C04F79FAA6}#1.0#0; wmp.dll
Reference=*\G{7C0FFAB0-CD84-11D0-949A-00A0C91110ED}#1.0#0#..\..\..\..\Windows\SysWOW64\msdatsrc.tlb#Microsoft Data Source Interfaces for ActiveX Data Binding Type Library
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll

---

It would not let me upload the different stdole2 files but

the windows 7 one was 16,896 bytes and last modified on ‎Monday, ‎July ‎13, ‎2009, ‏‎6:43:54 PM

windows 11 one was 18,432 bytes and last modified at ‎Saturday, ‎June ‎05, ‎2021, ‏‎7:05:44 AM

Let me know what you think

Well its time to eat crow!!!

I found the issue , it was related to a different version of a dll. Instantiation order made it look like something else.

I guess the whole no support for win10-11 make me doubt it.

So with process of elimination I found the issue.

Sorry for the trouble

Quote:

---

Originally Posted by baka

it gives me issues sometimes. theres kind of glitches. incorrect values, strange crashes etc. people report tons of "new" bugs. strange bugs that are impossible to fix. and know this, I have tried. for some time I compiled it in windows 10. it was hell. (I mean, its not that it gives the same bug all the time. its almost random and not all the time)

so, I don't dare move to windows 10/11, because I dont want to spend all my time trying to fix bugs are should not be there. no matter how much I look into the code, it doesn't make sense.
its like the EXE is corrupted, injected with a virus or something oddly. (of course not, but the EXE is bad)

---

Just wanted to add my two cents here. What you described above is textbook definition of using advanced compiler optimizations from project properties -> compile tab. If something goes wrong there you will get exactly the random behavior you described. It may be something worth looking into.

right now I use windows 7 and its working properly.
and I think, when its time for me to move to windows 10+ I will be using TwinBasic.

could be the optimization as u say. but for now I don't dare to look into it since it could eat away precious time that I can use for something else.

Most of those optimizations are likely to cause more harm than good. You won't see any speed increase especially on modern hardware. The only optimization that does have a visible result is the array bounds check and even then you will only see the benefit if you are using multiple nested loops within multi-dimensional arrays. It shouldn't eat too much of your time to compile the program without optimizations and see how it goes.

no, to compile it is fast. but to test it out will demand time.
when I used windows 10 and released my program, it took a bit before I got feedback.
and its not something u enjoy. people telling about strange behavior, crashes, corrupted screen, wrong numbers on stuff, missing items etc.
its not that I can test it myself only, I need people doing the testing and its not something I want to demand on the testers if the windows 7 version works.
they are needed for the game itself, not me trying to compile it in windows 10.
but I get what u mean. to figure it out there is need of testing.
but as I wrote, the game is made in windows 7 and Im comfortable with it now and its working. dont want to mess with that.
next project that I will begin next year, maybe. but Im quite curious if I can use TwinBasic, so this is all futile in the end.

https://youtu.be/zK9QUlJLNTA

The black guy here is the user, not the programmer who cobbled this mess together.

Recently I found a problem with timeGetTime in windows 10 pro. It should be a timer which updated from the startup. Vb6 read this as a Long value, but it is an unsigned long, which means for a cycle of 49 days, at the middle, turn to negative value. The problem is that some time this value turn to be negative from the startup. Maybe some other program handle the library behind timeGettime,Winmm.dll and change the 'base" value to negative. So I change it to this:

Code:

---

Private Declare Function timeGetTime Lib "Kernel32.dll" Alias "GetTickCount" () As Long

---

The GetTickCount is like timeGetTime with a steady resolution.

Also I found a way to overcome the negative turn (if happen, for GetTickCound, randomly, but for sure after 24+ days, which isn't something which will face the user).
The first line just exit from the "handling sub", the second line reload the time stamp. Maybe the first check will be less than the delay i wish but later this will be fix automatic.

Code:

---

If (timeGetTime And &H7800) = timestamp Then Exit Sub
timestamp = timeGetTime And &H7800

---

timeGetTime and GetTickCount are two different functions with different accuracies (the former is more precise). It doesn't make sense to alias one for the other. They both wrap around in intervals of 2^32. So if you get a negative value simply add 2^32 to it but you have no way of knowing how many such 2^32 intervals have been wrapped around (assuming it was more than one). MSDN states that:

"Note that the value returned by the timeGetTime function is a DWORD value. The return value wraps around to 0 every 2^32 milliseconds, which is about 49.71 days.This can cause problems in code that directly uses the timeGetTime return value in computations, particularly where the value is used to control code execution. You should always use the difference between two timeGetTime return values in computations."

Btw, this timeGetTimeEx declaration works

Code:

---

Option Explicit

Private Declare Function timeGetTimeEx Lib "Kernel32.dll" Alias "timeGetTime" () As Currency
Private Declare Function timeGetTime Lib "Kernel32.dll" () As Long

Private Sub Form_Load()
    Debug.Print timeGetTimeEx, timeGetTime
End Sub

---

. . . and timeGetTimeEx * 10000@ is never negative.

cheers,
</wqw>

The problem is not about accuracy, not for negative values also (these can be compensated). Is about the unknown reason of the changing of the value of timer. So the negative value was an event for me to understand that something going wrong. Perhaps some other times the timer value stay positive, at a random value, and the "interval' supposed I have to take account may never happen. From that point the Windows cause troubles for everyone. Maybe is the motherboard, I don't know. This is a simple warning to care about that timer.

It has been documented that TickCount functions can be inaccurate in Windows 10 because of the Fast Startup feature, which is enabled by default in W10. This came up during a routine Google search so you may give it a shot.

Quote:

---

Originally Posted by georgekar

Code:

---

Private Declare Function timeGetTime Lib "Kernel32.dll" Alias "GetTickCount" () As Long

---

---

Since Vista you can use the GetTickCount64-API which cannot overflow anymore:
https://learn.microsoft.com/en-us/wi...gettickcount64

Olaf