https://bugs.winehq.org/show_bug.cgi?id=50122
Bug ID: 50122 Summary: InternetOpenURL() from wininet.dll(v8.00.7601.17601) on wine vUbuntu 5.0-3ubuntu1 throws 12006 ERROR_INTERNET_UNRECOGNIZED_SCHEME Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: wininet Assignee: wine-bugs@winehq.org Reporter: guscarreno@gmail.com Distribution: ---
Hi there,
I stumbled upon this issue when HeidiSQL's update checker began to fail to contact the mother ship.
I then had a very long back and forth with a troll but that ended when the main developer of HeidiSQl stepped in and I decided to replicate the update check code under Lazarus.
I used fpcupdeluxe to install Lazarus and copied the offending code and had a go.
I can report that I've tried to access:
1. https://www.heidisql.com/updatecheck.php?r=6119&bits=64 2. http://www.heidisql.com/updatecheck.php?r=6119&bits=64 3. ftp://www.heidisql.com/updatecheck.php?r=6119&bits=64 (Yes in desperation) 4. I now need to test if the "file:///" SCHEMA doesn't trip this wire
All of the above have always given me a GetLastError()==12006
As stated on summary:
- wininet.dll version is 8.00.7601.17601 as reported from Sysinternals's sigcheck - wine --version return "wine-5.0 (Ubuntu 5.0-3ubuntu1)" - My system is Ubuntu 20.10 64b with wine64 and wine32 installed and updated as of 2020/11/11 - Tested with InternetOpenURL() - Tested with InternetOpenURLA() (I really don't know what I'm doing here)
If you really insist I can probably conjure up some C code to test this. At the moment I only have Free Pascal code that I can provide.
Cheers, Gus
https://bugs.winehq.org/show_bug.cgi?id=50122
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Severity|blocker |normal
--- Comment #1 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Issue is not a blocker. From the given description the severity level should be 'normal'. Read more about severity levels description there: https://wiki.winehq.org/Bugs#severity
(In reply to Gustavo Carreno from comment #0)
I stumbled upon this issue when HeidiSQL's update checker began to fail to contact the mother ship.
Is it after a Wine update (→regression) or application update, or neither?
I can report that I've tried to access:
- https://www.heidisql.com/updatecheck.php?r=6119&bits=64
- http://www.heidisql.com/updatecheck.php?r=6119&bits=64
- ftp://www.heidisql.com/updatecheck.php?r=6119&bits=64 (Yes in desperation)
- I now need to test if the "file:///" SCHEMA doesn't trip this wire
Can you give step by step instructions for other people to reproduce the issue?
- wininet.dll version is 8.00.7601.17601 as reported from Sysinternals's
sigcheck
Do you mean that you're overriding wininet.dll with a native one? You have to tell your exact wine config (DLL overrides, winetricks used, non-default settings in registry or winecfg, etc.).
- wine --version return "wine-5.0 (Ubuntu 5.0-3ubuntu1)"
Bug reports should be filed against wine-devel/wine-staging, not wine-stable. Wine-stable doesn't have all the latests features and fixes. Please update to a recent wine-devel/wine-staging (current is 5.21) and retest. https://wiki.winehq.org/Ubuntu
If you really insist I can probably conjure up some C code to test this. At the moment I only have Free Pascal code that I can provide.
It would be better if the issue could be reproduced with a freely and legally downloadable application.
If you know one then please fill the URL field with the link to the download page on the vendor website and add the download keyword.
If there is none, then yes, a sample application with its source code is better than nothing.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=50122
--- Comment #2 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Gustavo Carreno from comment #0)
I stumbled upon this issue when HeidiSQL's update checker began to fail to contact the mother ship.
The AppDB entry for HeidiSQL has more than one version. Please mention your version number so that I may link the bug to the appropriate AppDB entry.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=50122
--- Comment #3 from Gustavo Carreno guscarreno@gmail.com --- (In reply to Olivier F. R. Dierick from comment #1)
Hello,
Hi there Olivier
Issue is not a blocker. From the given description the severity level should be 'normal'. Read more about severity levels description there: https://wiki.winehq.org/Bugs#severity
For that I apologise. It's my first bug report and I'm prone to step on some toes now and again. You'll see me apologise for that many times :)
But from my very narrow knowledge, Ubuntu packages are distributing stable aren't they? Again, sorry if I'm stuffing my mouth with my foot.
And to be quite honest, this issue only appeared recently. I'm guessing with Ubuntu 20.04. Or when ever the Ubuntu packaging team decided to overhaul wine. I can't quite put my finger on it, but it's either after 20.04 or a month or two before 20.10. Somehow there wininet stopped working. The code that triggers this issue on HeidiSQL is very stale, very stale indeed!
The packages are so messed up that wine-gecko is no longer installed and upon creating a new prefix, no question is asked if I want to install it...
(In reply to Gustavo Carreno from comment #0)
I stumbled upon this issue when HeidiSQL's update checker began to fail to contact the mother ship.
Is it after a Wine update (→regression) or application update, or neither?
I've tested on an old prefix, then completely erased it and started fresh.
I've also tested this on an Ubuntu machine that hadn't wine yet, did a [code] sudo apt install wine [/code]
immediately followed by [code] wine HeidiSQL-Setup.exe [/code]
So there was no messing with the default install. All pure and pristine as intended by the Ubuntu package managers for 20.10.
I can report that I've tried to access:
- https://www.heidisql.com/updatecheck.php?r=6119&bits=64
- http://www.heidisql.com/updatecheck.php?r=6119&bits=64
- ftp://www.heidisql.com/updatecheck.php?r=6119&bits=64 (Yes in desperation)
- I now need to test if the "file:///" SCHEMA doesn't trip this wire
Can you give step by step instructions for other people to reproduce the issue?
Sure:
1. On the initial Connection dialog 2. On the arrow next to the More button 3. Choose Check for updates.
If in the main form:
1. Goto the Help menu 2. Choose Check for Updates
- wininet.dll version is 8.00.7601.17601 as reported from Sysinternals's
sigcheck
Do you mean that you're overriding wininet.dll with a native one? You have to tell your exact wine config (DLL overrides, winetricks used, non-default settings in registry or winecfg, etc.).
The prefixes I tested are as pristine as can be since I completely deleted my $HOME/.wine many times in the several tests and never did any winetricks on it. The other test machine did not have wine installed and right after the installation I called wine to install HeidiSQL, so pretty pristine. I'm reporting wininet's version number for completeness and in an effort to add more info to help on the bug squashing.
- wine --version return "wine-5.0 (Ubuntu 5.0-3ubuntu1)"
Bug reports should be filed against wine-devel/wine-staging, not wine-stable. Wine-stable doesn't have all the latests features and fixes.
I agree that that is a great idea in itself, but by saying that you are stranding all Ubuntu users that try out wine. Ubuntu 20.10 comes with wine 5.0 and the *.desktop files get created calling wine-stable, so you are leaving a load of folks in the sun to dry.
Please update to a recent wine-devel/wine-staging (current is 5.21) and retest. https://wiki.winehq.org/Ubuntu
If you really insist I can probably conjure up some C code to test this. At the moment I only have Free Pascal code that I can provide.
It would be better if the issue could be reproduced with a freely and legally downloadable application.
HeidiSQL is an open source and you have it on your AppDB with id 3326.
If you know one then please fill the URL field with the link to the download page on the vendor website and add the download keyword.
Done and done.
If there is none, then yes, a sample application with its source code is better than nothing.
I hope you guys attach gdb to the process and debug it that way, cuz if you're gonna rely on what HeidiSQL tells you visually, that's nothing. Only recently(Build 6120) did the main dev add a call to GetLastError() because of me first reporting this error to their GitHub Issues.
To try and debug the issue I made a copy of HeidiSQL's Delphi code and, using Free Pascal/Lazarus, was able to find that InternetOpenUrl() was returning a 12006.
I can also point you to: https://github.com/HeidiSQL/HeidiSQL/blob/master/source/updatecheck.pas at about line 140 where it calls the update checker object.
And point you to: https://github.com/HeidiSQL/HeidiSQL/blob/master/source/apphelpers.pas at about line 3332 where the call to InternetOpen() starts the whole process.
Regards.
Thanks and to you too.
Cheers, Gus
https://bugs.winehq.org/show_bug.cgi?id=50122
--- Comment #4 from Gustavo Carreno guscarreno@gmail.com --- Hi there Olivier,
(In reply to Olivier F. R. Dierick from comment #2)
(In reply to Gustavo Carreno from comment #0)
I stumbled upon this issue when HeidiSQL's update checker began to fail to contact the mother ship.
The AppDB entry for HeidiSQL has more than one version. Please mention your version number so that I may link the bug to the appropriate AppDB entry.
The latest Release version is 11.1 and the latest build version is 11.1.0.6120
Regards.
Thanks and to you too.
Cheers, Gus
https://bugs.winehq.org/show_bug.cgi?id=50122
Gustavo Carreno guscarreno@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.heidisql.com/dow | |nload.php Distribution|--- |Ubuntu Keywords| |download