I understand that.
I can also code in c++ so it’s not a problem to make something for stuff non-windows too.
@SoniX
I would say to test bytes 12-16 or 0xC-0x10. If they are 0000000000, then size of version is 0x18 and version is 3.0.15.1016, but display 3.0.1016 anyway. If bytes 0xC-0x10 are different then 0000000000, then size of version is 0x10 and version is 3.0.1016, display 3.0.1016.
The reason is, even if version is something like 0.0.0000, bytes 0xC-0x10 would still be 0030003000.
Edited:
We need to account for Broadwell too. If bytes 0xC-0x10 and 0x12-0x16 are 0000000000, then it is Broadwell and size of version is 0xC, version is like 5.1018, but display 5.5.1018.
If only bytes 0xC-0x10 are 0000000000, then size of version is 0x18, version is like 3.0.15.1016, display 3.0.1016.
If bytes 0xC-0x10 are NOT 0000000000, then size of version is 0x10, version is like 3.0.1016, display 3.0.1016.
This we specifically "15" cut to confuse not forced down, and it was a lot of questions: "What is a newer version?".
Ok. Think then another over the output version.
Add
@lordkag
If you are not hard to send version 2.x…x, which is also not defined.
I have edited my previous post for Broadwell.
I don’t think that middle group is important. Not likely you would see 2.0.15.1016 and 2.0.18.1016, for instance. For example, I have Sandy GOP 2.0.35.1018 and 2.0.36.1019 in my folder of modules. They were definitely released one after the other, so the middle group follows last build.
Here is what I have extracted.
Intel GOP.rar (478 KB)
@lordkag
GOP Broadwell we still have one and it appears correctly, 5.5.1018. There will be more versions will look.
By version 2/3.0.xx.zzzz "old format". Value in the middle is not critical (.xx.), but not for experienced users can be misleading, so we tried to exclude from the display. If for you it is also not critical, then leave it as is. Will only find a solution to version 3.0.1020.
Thank you for your art collection. 
Yes, you can exclude it, since it is not important. Print only 2.0.xxxx/3.0.xxxx/5.0.xxxx/5.5.xxxx.
Please note that there are also Sandy GOP that are in the format 2.0.xxxx, like 2.0.1023, 2.0.1024 and so on. So you need to test those bytes and decide for all the variants out there. At least we don’t need to use the EFI Shell like in Atheros case, so I would say it is not that bad.
Sorry, I did not quite understand. But this collection shows the version goes well. If only older version, which I do not.
It is indeed odd. So it might be a bug in there, in the modules. Check Z77X-UP5-TH BIOS F12, they both appear as 2.0. and 3.0. when it should be 2.0.1020 and 3.0.1018.
GOP bug.rar (44.2 KB)
Yes. 2.0.1020 and 3.0.1018 -> 2.0 and 3.0. A similar problem as with version 3.0.1020.
Let us think. 
You need to drop — has_rev = (check[2] == 0x2E); — since it is not reliable because of above bugged modules, instead use the method from here. Or at least this is my first impression.
Or search until you reach FF, then go back 5 bytes, which will be the end of version. Then based on the length (0x10, 0x18, 0xC) you extract only relevant bytes.
@lordkag
Until I found one solution. Changes in the code on GitHub. if only will not get very radical version.
Meet version DrvVer 0.9.2
@All
I ask everyone who uses UBU 1.6.1 and later, update the file DrvVer.
If there are problems in displaying GOP versions soobshaet immediately.
Edit:
Included in UBU v1.7.0
report.txt (1.16 KB)
Hello i would like to ask how do you check if MMTool got a error or not like could not find bios file or something using the command prompt.
I am developing my own BIOS modding feature to put into my program and i would like to be able to error check it.
Unfortunately nothing. MMTool has no return errorlevel. Instead, he gives out error messages on the screen, which is extremely convenient.
Issue is though MMTool opens up in another window it doesn’t give output to the same cmd window.
So how do i capture the error that says file not found if MMTool is open in the background.
Hi, i’ve succesfully updated the most of the oroms on my mb asrock z77 oc formula thanks to UBU. My only problem is that i have two marvell 9172 onboard controllers to update and ubu only updates the first three distinct marvell modules it finds.
Ubu in main menu detects a total of 6 marvell modules: 2 for mv9172, 2 for mv927a and 2 for 9192 but after the update only 1 for each chipset is updated. Can be fixed in future release? In the meantime i’ll try to do it manually using mmtool.
Yup, that’s what I meant. Had not seen it mentioned before so figured I’ll post/ask but seems it’s known.
@ GlitchyHack
The window that opens when MMTul error, has nothing to do with the windows command processor Windows.
@ Herrnobiz
Unfortunately, using MMTool, nothing can be done. If only remove 2 modules 9172 and 917a.
@ error-id10t
Problem confirmed your message, no one had unsubscribe to it. There was hope that someone module works, but apparently not.
I think, or will return the version 6.1.16 (it work) or wait 6.3.hh version (should have come out)
@SoniX
Yes, it works. I have checked with all the Intel GOPs I have. But the intriguing part is that —if ((check[2] == 0x2E) || (check[2] == 0x00) || (check[10] != 0x00))— always evaluates to true, isn’t it?
Wouldn’t —if (check[12] == 0x00)— be the better option? No need to change drvver again, since it already works. I’m just wondering.
@Fernando
Am I the only one who finds this message intriguing? I do hope I will be wrong and embarrassed by finding that the tool will be for personal use only or totally something else than UBU, because the alternative is unsettling.
Sure, MMTool is available for anyone to use, it has a list of commands, nothing secret about that. But UBU is more than a wrapper for MMTool. It was developed by Sonix (and maybe others? Maybe Coderush?), it was supported by the community, it was refined by feedback, hints and ideas. In a sentence, developed by Sonix, powered by community.
How can anyone release a competing product and complete as UBU, without copying UBU? It will be pretty hard to state that no code was borrowed, behind a closed source. And again, why should anyone take an open source project as UBU and turn it into a separate one? This will only force Sonix to lock his UBU and possibly remove it from win-raid.
I do hope I’m wrong, because otherwise I would think twice about being part of a community that approves this kind of treatment. Either this is a project that gets backed up by the forum/community (most desirable), or it is each on its own with his own ideas (less desirable). I would be disappointed to see the author of UEFI Download Tool going down this path. I offer you my apologies, if I should be proven wrong in my assumptions.
@ lordkag:
I can understand your worries, but I assure you, that I will do everything I can to prevent, that they come true.
Some weeks ago GlitchyHack told me me via PM, that he was thinking about the implementation of new features like BIOS modding into his “UEFI Download Tool” (look >here<) and asked me for the UBU tool source code.
My answers were:
- SoniX is the developer and main author of the UBU tool. He alone decides, if anyone else may use parts of his code.
- I will not allow anyone to use my Forum for the presentention of a tool, which is doing the same as the UBU tool does.
He accepted that.
Even I do not know how, pure intuition. 
I have a couple of ideas on how to do a background check for Intel GOP versions 2 and 3. I’ll check them and your idea too, as soon as I have time to add another block of code to support the next module EFI.
EDIT by Fernando: Quoting code corrected