{"id":261064,"date":"2021-12-31T11:40:10","date_gmt":"2021-12-31T10:40:10","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=261064"},"modified":"2021-12-31T11:42:19","modified_gmt":"2021-12-31T10:42:19","slug":"der-8-jahre-alte-bug-in-64-bit-vba","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2021\/12\/31\/der-8-jahre-alte-bug-in-64-bit-vba\/","title":{"rendered":"Der 8 Jahre alte Bug in 64-Bit-VBA"},"content":{"rendered":"<p><img loading=\"lazy\" decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2012\/07\/Office1.jpg\" width=\"55\" align=\"left\" height=\"60\"\/>Denkt ihr aktuell \u00fcber einen Umstieg von 32-Bit auf ein 64-Bit-Office nach. In Firmen k\u00f6nnte dieser Schritt m\u00f6glicherweise tzz Problemen f\u00fchren. Denn in der 64-Bit-Version von Visual Basic for Applications (VBA) gibt es unter Windows einen Compiler-Fehler, der seit Jahren nicht behoben worden ist. Die Migration zu einem 64-Bit-Office sollte daher \u00fcberlegt werden. Ich hole mal einen Sachverhalt hervor, der mit bereits im August 2021 unter die Augen gekommen ist.<\/p>\n<p><!--more--><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" alt=\"\" src=\"https:\/\/vg09.met.vgwort.de\/na\/30a4cc6de6e6423f865ac7541fa74a22\" width=\"1\" height=\"1\"\/>Ich bin bei The Register \u00fcber <a href=\"https:\/\/www.theregister.com\/2021\/08\/19\/64_bit_microsoft_vba_bug\/\" target=\"_blank\" rel=\"noopener\">diesen Beitrag<\/a> auf das Thema aufmerksam geworden. Das Ganze ist Mitte 2021 bereits bei Stack Overflow in <a href=\"https:\/\/stackoverflow.com\/questions\/68034271\/how-can-i-get-this-8-year-old-vba-64-bit-compiler-bug-fixed\" target=\"_blank\" rel=\"noopener\">diesem Post<\/a> aufgegriffen worden. Der Betroffene hat das Problem mit einem kurzen Quellcode-Beispiel demonstriert.<\/p>\n<pre>' this needs to be here to trigger the bug: \nPrivate Sub Class_Terminate()\nEnd Sub<\/pre>\n<pre><code>Function ReturnFalse(o As Object) As Boolean\n    ReturnFalse = False\nEnd Function\n\nSub Test()\n    Debug.Print ReturnFalse(New SomeClass)\n    If ReturnFalse(New SomeClass) Then\n        Debug.Print True\n    Else\n        Debug.Print False\n    End If    \nEnd Sub<\/code><\/pre>\n<p>Wird der Funktionsaufruf <em>ReturnFalse&nbsp; <\/em>in einer 32-Bit-VBA-Umgebung ausgef\u00fchrt, liefert diese das erwartete Resultat FALSE FALSE zur\u00fcck. In einer 64-Bit-VBA-Umgebung kommen jedoch die Resultat FALSE TRUE zur\u00fcck. Der Thread-Ersteller hat den Fehler bis auf dieses minimale Beispiel zur\u00fcckverfolgt. <\/p>\n<p>Anscheinend liegt das Problem darin, dass die Verwendung eines tempor\u00e4ren Objekts (hier <em>new SomeClass<\/em>) die Auswertung der IF-Bedingung irgendwie unterbricht. Es sieht so aus, als ob der Wert der Bedingung True ist, egal was passiert. Das ist ein schwerwiegender Fehler, denn der 64-Bit-Compiler spinnt und damit sind alle IF-Abfragen nicht mehr vertrauensw\u00fcrdig. <\/p>\n<p>Laut The Register wurde der Bug bereits 2018 in Excel User Voice an Microsoft gemeldet (der Beitrag wurde entfernt). Der Fehler besteht wahrscheinlich schon seit Jahren, m\u00f6glicherweise seit der Einf\u00fchrung von 64-Bit-VBA in Office 2010. Der StackOverflow-Benutzer konnte diesen Fehler in allen Versionen von Office finden, beginnend mit 2013. Der Bug ist wahrscheinlich mindestens 8 Jahre alt. Der Fehler tritt in VBA auf dem Mac nicht auf. Ich kann es aktuell nicht testen &#8211; aber es sieht nicht so aus, als ob der Bug bisher behoben wurde. Irgend jemand mit einem 64-Bit-Office, der das verifizieren kann?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Denkt ihr aktuell \u00fcber einen Umstieg von 32-Bit auf ein 64-Bit-Office nach. In Firmen k\u00f6nnte dieser Schritt m\u00f6glicherweise tzz Problemen f\u00fchren. Denn in der 64-Bit-Version von Visual Basic for Applications (VBA) gibt es unter Windows einen Compiler-Fehler, der seit Jahren &hellip; <a href=\"https:\/\/borncity.com\/blog\/2021\/12\/31\/der-8-jahre-alte-bug-in-64-bit-vba\/\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7459],"tags":[3836],"class_list":["post-261064","post","type-post","status-publish","format-standard","hentry","category-software","tag-software"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/261064","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=261064"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/261064\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=261064"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=261064"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=261064"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}