Core ReactOS
  1. Core ReactOS
  2. CORE-12229

[msi?] required disk-space negative in MSExcel Viewer2007 when ros setup german localization

    Details

    • Type: Bug Bug
    • Status: Untriaged Untriaged
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      r73036 is affected

      Microsoft Excel Viewer 2007 installer reports negative required disk space of "-789054976bytes".
      happens only if german localization is selected during ros setup, when english ros setup is selected it's fine.
      The results seem to be biased sporadically additionally, be careful when interpreting therefore the following test:
      CORE-12229-requiredSize-regressionTest.txt

      (IIRC using r73036 also "OpenOffice 5.1.5.2" required "0bytes", so I guess we have a structural issue here)

      Maybe a very hard to solve ticket...

      1. CORE-12229-requiredSize-regressionTest.txt
        2 kB
        reactosfanboy
      2. Debug01.txt
        2 kB
        Doug Lyons
      3. Debug02.txt
        2 kB
        Doug Lyons
      4. dialog.c.patch
        0.8 kB
        Mark Jansen
      5. MIS_Costing2.txt
        2 kB
        Doug Lyons
      6. MSI_Costing1.txt
        2 kB
        Doug Lyons
      7. MSI_Costing3.txt
        2 kB
        Doug Lyons
      8. r73036-BSOD-MSExcelViewer2007.log
        1.03 MB
        reactosfanboy
      9. r73519-react-DebugChannelShell.log
        509 kB
        reactosfanboy
      10. shlwapi_StrFormatByteSizeW_apitest.patch
        6 kB
        Doug Lyons
      11. shlwapi_StrFormatByteSizeW_apitest.patch
        6 kB
        Doug Lyons
      1. 2K3_SP2-worksPerfectly-ActiveShimView.png
        35 kB
      2. ExcelViewerInstall_WinXP_DriveF.png
        8 kB
      3. ExcelViewerInstall_WinXP_LimitedMem.png
        10 kB
      4. ExcelViewerInstall73503_Fix1.png
        68 kB
      5. ExcelViewerInstall73503.png
        139 kB
      6. r73036-BSOD-duringInstallationOf-MS-ExcelViewer2007.png
        53 kB
      7. r73036-requiredSizeNegativeWhenRosIsGerman.png
        37 kB
      8. r73519-Office2000setupIsAffectedAsWell.png
        44 kB
      9. snapshot44.png
        73 kB

        Issue Links

          Activity

          Hide
          reactosfanboy
          added a comment - - edited

          cc Amine Khaldi due to wine-syncs.
          I intend to do some regression tests here soon...

          Show
          reactosfanboy
          added a comment - - edited cc Amine Khaldi due to wine-syncs. I intend to do some regression tests here soon...
          Hide
          reactosfanboy
          added a comment -

          r73036-BSOD-MSExcelViewer2007.log covers the setup process, but does end with another BSOD later on the setup process that is unrelated...

          Show
          reactosfanboy
          added a comment - r73036-BSOD-MSExcelViewer2007.log covers the setup process, but does end with another BSOD later on the setup process that is unrelated...
          Hide
          reactosfanboy
          added a comment - - edited

          CORE-12229-requiredSize-regressionTest.txt
          The results of these calculations are very volatile.
          I could not prove any regression since latest release, (but was just lucky once tricking me into thinking it was a regression).
          Please create some automated test for these kinds of calculations by msi.
          There seems to be something sporadic going on.

          Show
          reactosfanboy
          added a comment - - edited CORE-12229-requiredSize-regressionTest.txt The results of these calculations are very volatile. I could not prove any regression since latest release, (but was just lucky once tricking me into thinking it was a regression). Please create some automated test for these kinds of calculations by msi. There seems to be something sporadic going on.
          Hide
          reactosfanboy
          added a comment -

          unrelated to topic:
          r73036-BSOD-MSExcelViewer2007.log
          shows at end BSOD 0x00000050 PAGE_FAULT_IN_NONPAGED_AREA
          I got it during installation of Excel Viewer 2007
          only one out of about 50tries:
          It happened here:
          r73036-BSOD-duringInstallationOf-MS-ExcelViewer2007.png
          Thomas Faber thinks it could be CORE-12121.

          Show
          reactosfanboy
          added a comment - unrelated to topic: r73036-BSOD-MSExcelViewer2007.log shows at end BSOD 0x00000050 PAGE_FAULT_IN_NONPAGED_AREA I got it during installation of Excel Viewer 2007 only one out of about 50tries: It happened here: r73036-BSOD-duringInstallationOf-MS-ExcelViewer2007.png Thomas Faber thinks it could be CORE-12121 .
          Hide
          jimtabor
          added a comment -

          This Excel View was just downloaded from the MSDN site. Installs and runs.

          Show
          jimtabor
          added a comment - This Excel View was just downloaded from the MSDN site. Installs and runs.
          Hide
          reactosfanboy
          added a comment -

          The old excel view also downloads and runs, this is nothing special.
          The ticket is about the negative disk-space requirement during setup, I fear some other (not all) msi-installers are affected by this issue too.
          And as said, you need luck and you need to use the german version of our PowerPoint viewer from rapps to see it in action.

          Show
          reactosfanboy
          added a comment - The old excel view also downloads and runs, this is nothing special. The ticket is about the negative disk-space requirement during setup, I fear some other (not all) msi-installers are affected by this issue too. And as said, you need luck and you need to use the german version of our PowerPoint viewer from rapps to see it in action.
          Hide
          reactosfanboy
          added a comment -

          switched to minor now that the crash is fixed and only the negative required install size persists.

          Show
          reactosfanboy
          added a comment - switched to minor now that the crash is fixed and only the negative required install size persists.
          Hide
          reactosfanboy
          added a comment -

          As I already presumed, this msi-issue is not limited to ExcelViewer2007.
          Because r73519-Office2000setupIsAffectedAsWell.png

          Show
          reactosfanboy
          added a comment - As I already presumed, this msi-issue is not limited to ExcelViewer2007. Because r73519-Office2000setupIsAffectedAsWell.png
          Hide
          Mark Jansen
          added a comment -

          What happens with german localization in Win2k3?

          Show
          Mark Jansen
          added a comment - What happens with german localization in Win2k3?
          Hide
          reactosfanboy
          added a comment -

          It works without any issue of course in W2K3.

          Show
          reactosfanboy
          added a comment - It works without any issue of course in W2K3.
          Hide
          Mark Jansen
          added a comment - - edited

          Can you run the attached application in W2k3, and when the setup is open,
          drag the crosshair over the setup window?

          Show
          Mark Jansen
          added a comment - - edited Can you run the attached application in W2k3, and when the setup is open, drag the crosshair over the setup window?
          Hide
          Katayama Hirofumi MZ
          added a comment -

          -1543931392 is 0xA3F97A00. The most significant bit of 0xA3F97A00 is set.
          -789054976 bytes is 0xFFFFFFF876FAB68A. That is beyond 32-bit.

          https://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shlwapi/string.c?revision=73290&view=markup#l2344

            if (llBytes < 1024)  /* 1K */
            {
              WCHAR wszBytesFormat[64];
              LoadStringW(shlwapi_hInstance, IDS_BYTES_FORMAT, wszBytesFormat, 64);
              snprintfW(lpszDest, cchMax, wszBytesFormat, (int)llBytes);
              return lpszDest;
            }

          Why negative at here?

          Show
          Katayama Hirofumi MZ
          added a comment - -1543931392 is 0xA3F97A00. The most significant bit of 0xA3F97A00 is set. -789054976 bytes is 0xFFFFFFF876FAB68A. That is beyond 32-bit. https://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shlwapi/string.c?revision=73290&view=markup#l2344 if (llBytes < 1024) /* 1K */ { WCHAR wszBytesFormat[64]; LoadStringW(shlwapi_hInstance, IDS_BYTES_FORMAT, wszBytesFormat, 64); snprintfW(lpszDest, cchMax, wszBytesFormat, (int)llBytes); return lpszDest; } Why negative at here?
          Hide
          Mark Jansen
          added a comment -

          Does string.c.patch solve the issue?

          Show
          Mark Jansen
          added a comment - Does string.c.patch solve the issue?
          Hide
          reactosfanboy
          added a comment -

          Mark Jansen I retried with [^string.c.patch].
          Unfortunately this does not change or fix anything.
          I also retested on W2K3SP2 again, have a look at the shims here:
          2K3_SP2-worksPerfectly-ActiveShimView.png

          Show
          reactosfanboy
          added a comment - Mark Jansen I retried with [^string.c.patch] . Unfortunately this does not change or fix anything. I also retested on W2K3SP2 again, have a look at the shims here: 2K3_SP2-worksPerfectly-ActiveShimView.png
          Hide
          reactosfanboy
          added a comment -

          r73519-react-DebugChannelShell.log
          shows the process with

          set DEBUGCHANNEL=+shell
          

          The code-flow does not even executed the code that was changed by
          [^string.c.patch]
          But we cross line2375 repeatedly, so you are looking in the correct file...

          Show
          reactosfanboy
          added a comment - r73519-react-DebugChannelShell.log shows the process with set DEBUGCHANNEL=+shell The code-flow does not even executed the code that was changed by [^string.c.patch] But we cross line2375 repeatedly, so you are looking in the correct file...
          Hide
          reactosfanboy
          added a comment - - edited

          For fun I injected/replaced our shlwapi.dll with that of 2k3SP2 v 6.0.3790.3959.
          ros r73519 still fails the same way then. Not sure which conclusions to draw from that.
          My naive thinking makes me believe this hints more towards a bug in msi than a bug in shlwapi.

          Show
          reactosfanboy
          added a comment - - edited For fun I injected/replaced our shlwapi.dll with that of 2k3SP2 v 6.0.3790.3959. ros r73519 still fails the same way then. Not sure which conclusions to draw from that. My naive thinking makes me believe this hints more towards a bug in msi than a bug in shlwapi.
          Hide
          reactosfanboy
          added a comment -

          adding a

          __debugbreak();

          at shlwapi/string.c line 2376 gives the following call-stack when O2Ksetup performs these calculations:

          trace:(../dll/win32/shlwapi/istream.c:249) (0170F9E0,0)
          trace:(../dll/win32/shlwapi/string.c:2375) (0x480e2ca00,0022F224,260)
           
          Entered debugger on embedded INT3 at 0x001b:0x7c1c0630.
          kdb:> bt
          Eip:
          <shlwapi.dll:20631 (dll/win32/shlwapi/string.c:2377 (StrFormatByteSizeW))>
          Frames:
          <msi.dll:314ba (dll/win32/msi/dialog.c:3192 (msi_dialog_vcl_add_drives))>
          <msi.dll:32919 (dll/win32/msi/dialog.c:3258 (msi_dialog_volumecost_list))>
          <msi.dll:2e52d (dll/win32/msi/dialog.c:3454 (msi_dialog_create_controls))>
          <msi.dll:55e50 (dll/win32/msi/msiquery.c:169 (MSI_IterateRecords))>
          <msi.dll:300d7 (dll/win32/msi/dialog.c:3481 (MSIDialog_WndProc))>
          <user32.dll:60999 (:0 (CALL_EXTERN_WNDPROC))>
          <user32.dll:54b97 (win32ss/user/user32/windows/message.c:1522 (IntCallWindowProcW))>
          <user32.dll:56992 (win32ss/user/user32/windows/message.c:2968 (User32CallWindowProcFromKernel))>
          <ntdll.dll:c770 (:0 (KiUserCallbackDispatcher))>
          <user32.dll:5da44 (win32ss/user/user32/windows/window.c:554 (CreateWindowExW))>
          <msi.dll:2f0eb (dll/win32/msi/dialog.c:3808 (dialog_run_message_loop))>
          <msi.dll:36643 (dll/win32/msi/dialog.c:4330 (event_do_dialog))>
          <msi.dll:37887 (dll/win32/msi/dialog.c:4516 (ACTION_DialogBox))>
          <msi.dll:138cb (dll/win32/msi/action.c:7818 (ACTION_PerformUIAction))>
          <msi.dll:13a4b (dll/win32/msi/action.c:490 (ITERATE_Actions))>
          <msi.dll:55e50 (dll/win32/msi/msiquery.c:169 (MSI_IterateRecords))>
          <msi.dll:14234 (dll/win32/msi/action.c:595 (MSI_InstallPackage))>
          <msi.dll:49450 (dll/win32/msi/msi.c:227 (MsiInstallProductW))>
          <msiexec.exe:2e1c (base/system/msiexec/msiexec.c:985 (WinMain))>
          <msiexec.exe:5688 (sdk/lib/crt/startup/crt0_c.c:20 (main))>--- Press q to abort, any other key to continue ---
           
          <msiexec.exe:4792 (sdk/lib/crt/startup/crtexe.c:311 (__tmainCRTStartup))>
          <msiexec.exe:47db (sdk/lib/crt/startup/crtexe.c:168 (WinMainCRTStartup))>
          <kernel32.dll:10442 (dll/win32/kernel32/client/proc.c:472 (BaseProcessStartup))>
          <00000000>

          Show
          reactosfanboy
          added a comment - adding a __debugbreak(); at shlwapi/string.c line 2376 gives the following call-stack when O2Ksetup performs these calculations: trace:(../dll/win32/shlwapi/istream.c:249) (0170F9E0,0) trace:(../dll/win32/shlwapi/string.c:2375) (0x480e2ca00,0022F224,260)   Entered debugger on embedded INT3 at 0x001b:0x7c1c0630. kdb:> bt Eip: <shlwapi.dll:20631 (dll/win32/shlwapi/string.c:2377 (StrFormatByteSizeW))> Frames: <msi.dll:314ba (dll/win32/msi/dialog.c:3192 (msi_dialog_vcl_add_drives))> <msi.dll:32919 (dll/win32/msi/dialog.c:3258 (msi_dialog_volumecost_list))> <msi.dll:2e52d (dll/win32/msi/dialog.c:3454 (msi_dialog_create_controls))> <msi.dll:55e50 (dll/win32/msi/msiquery.c:169 (MSI_IterateRecords))> <msi.dll:300d7 (dll/win32/msi/dialog.c:3481 (MSIDialog_WndProc))> <user32.dll:60999 (:0 (CALL_EXTERN_WNDPROC))> <user32.dll:54b97 (win32ss/user/user32/windows/message.c:1522 (IntCallWindowProcW))> <user32.dll:56992 (win32ss/user/user32/windows/message.c:2968 (User32CallWindowProcFromKernel))> <ntdll.dll:c770 (:0 (KiUserCallbackDispatcher))> <user32.dll:5da44 (win32ss/user/user32/windows/window.c:554 (CreateWindowExW))> <msi.dll:2f0eb (dll/win32/msi/dialog.c:3808 (dialog_run_message_loop))> <msi.dll:36643 (dll/win32/msi/dialog.c:4330 (event_do_dialog))> <msi.dll:37887 (dll/win32/msi/dialog.c:4516 (ACTION_DialogBox))> <msi.dll:138cb (dll/win32/msi/action.c:7818 (ACTION_PerformUIAction))> <msi.dll:13a4b (dll/win32/msi/action.c:490 (ITERATE_Actions))> <msi.dll:55e50 (dll/win32/msi/msiquery.c:169 (MSI_IterateRecords))> <msi.dll:14234 (dll/win32/msi/action.c:595 (MSI_InstallPackage))> <msi.dll:49450 (dll/win32/msi/msi.c:227 (MsiInstallProductW))> <msiexec.exe:2e1c (base/system/msiexec/msiexec.c:985 (WinMain))> <msiexec.exe:5688 (sdk/lib/crt/startup/crt0_c.c:20 (main))>--- Press q to abort, any other key to continue ---   <msiexec.exe:4792 (sdk/lib/crt/startup/crtexe.c:311 (__tmainCRTStartup))> <msiexec.exe:47db (sdk/lib/crt/startup/crtexe.c:168 (WinMainCRTStartup))> <kernel32.dll:10442 (dll/win32/kernel32/client/proc.c:472 (BaseProcessStartup))> <00000000>
          Hide
          Mark Jansen
          added a comment -

          Ok, german file is bigger.

          This is german setup in my msvc ros:

          Show
          Mark Jansen
          added a comment - Ok, german file is bigger. This is german setup in my msvc ros:
          Hide
          Mark Jansen
          added a comment -

          Roughly same environment,
          gcc build:

          Show
          Mark Jansen
          added a comment - Roughly same environment, gcc build:
          Hide
          Doug Lyons
          added a comment -

          I added another TRACE statement to show the actual text to match the HEX numbers and ran the install in English and collected the Debug Output which is attached along with a screen capture. I think that it shows what may be the source of the error fairly clearly. Hopefully someone with real programming skills can use this to fix the problem.

          Show
          Doug Lyons
          added a comment - I added another TRACE statement to show the actual text to match the HEX numbers and ran the install in English and collected the Debug Output which is attached along with a screen capture. I think that it shows what may be the source of the error fairly clearly. Hopefully someone with real programming skills can use this to fix the problem.
          Hide
          victor martinez calvo
          added a comment -

          Thanks Doug,
          Your debug points directly to the issue imho,

          • This is the important llne:
            trace../dll/win32/shlwapi/string.c:2375) (0xffffffffa0e50400,0022F424,260)
            This trace shows which params are being received by StrFormatByteSizeW()
            Obviously that 0xfffffff...is wrong and hence leads to a negativenumber.
            So the culprit here is the API calling and passing such param to StrFormatByteSizeW.
            If we look carefully to such number, 0xffffffffa0e50400,I can imagine a wrong manipulation with 0xffffffff and 0xa0e5040. Maybe we should crop to the first 8 bytes and not using 16 bytes to calculate the number of bytes?
            0xa0e5040 is roughly 2,6GB which could be the expected number.
          Show
          victor martinez calvo
          added a comment - Thanks Doug, Your debug points directly to the issue imho, This is the important llne: trace ../dll/win32/shlwapi/string.c:2375) (0xffffffffa0e50400,0022F424,260) This trace shows which params are being received by StrFormatByteSizeW() Obviously that 0xfffffff...is wrong and hence leads to a negativenumber. So the culprit here is the API calling and passing such param to StrFormatByteSizeW. If we look carefully to such number, 0xffffffffa0e50400,I can imagine a wrong manipulation with 0xffffffff and 0xa0e5040. Maybe we should crop to the first 8 bytes and not using 16 bytes to calculate the number of bytes? 0xa0e5040 is roughly 2,6GB which could be the expected number.
          Hide
          victor martinez calvo
          added a comment -

          Ok, so the first thing we should test is what happens in Windows when StrFormatByteSizeW is feed with a monster as 0xffffffffa0e5040. Does it return a negative number or does it detect that it should ignore the first 8 "f" because we are in a 32 bits system. Somehow the Notes(and the implementation)of the function implies that this API could manage and should recognize up to 2^64 numbers. If it does, then we very first thing we should do in the StrFormatByteSizeW is to ignore the first 8"f"(since that points we are in a 32 bits OS or processing a number below 2^32 in a 64 bit OS) before doing the check:

          1. if (llBytes < 1024) /* 1K */
            Since llBytes is 0xf.....then it is interpreted as a negative number, so it is below 0, we fall in the if trap and a negative number is printed.
            A highly doubt this would work, but you may try replacing
            If (llBytes < 1024) with
            If ((llBytes < 1024) && (llBytes >= 0))
            Maybe any of the next calls would take care of stripping the first 8"f". This is hackish, probably not working and also this open a question: Is this API supposed to return NEGATIVE sizes?
            If so, the best approach is, as said, checking if there are 8 consecutive "f"s in the hex number, and if so, steipping them to manipulate it correctly.
          Show
          victor martinez calvo
          added a comment - Ok, so the first thing we should test is what happens in Windows when StrFormatByteSizeW is feed with a monster as 0xffffffffa0e5040. Does it return a negative number or does it detect that it should ignore the first 8 "f" because we are in a 32 bits system. Somehow the Notes(and the implementation)of the function implies that this API could manage and should recognize up to 2^64 numbers. If it does, then we very first thing we should do in the StrFormatByteSizeW is to ignore the first 8"f"(since that points we are in a 32 bits OS or processing a number below 2^32 in a 64 bit OS) before doing the check: if (llBytes < 1024) /* 1K */ Since llBytes is 0xf.....then it is interpreted as a negative number, so it is below 0, we fall in the if trap and a negative number is printed. A highly doubt this would work, but you may try replacing If (llBytes < 1024) with If ((llBytes < 1024) && (llBytes >= 0)) Maybe any of the next calls would take care of stripping the first 8"f". This is hackish, probably not working and also this open a question: Is this API supposed to return NEGATIVE sizes? If so, the best approach is, as said, checking if there are 8 consecutive "f"s in the hex number, and if so, steipping them to manipulate it correctly.
          Hide
          Mark Jansen
          added a comment -

          A testcase for this would be nice, but I suspect a bug in msi, pointed out by the testlog from reactosfanboy.

          Show
          Mark Jansen
          added a comment - A testcase for this would be nice, but I suspect a bug in msi, pointed out by the testlog from reactosfanboy .
          Hide
          Mark Jansen
          added a comment - - edited

          dialog.c.patch might resolve it.

          victor martinez calvo: Stripping those bytes sounds an aweful lot like a workaround for buggy applications.

          Show
          Mark Jansen
          added a comment - - edited dialog.c.patch might resolve it. victor martinez calvo : Stripping those bytes sounds an aweful lot like a workaround for buggy applications.
          Hide
          Doug Lyons
          added a comment -

          Results with dialog.c.patch shows changes, but still we have negative numbers. They are in different places now though.

          Show
          Doug Lyons
          added a comment - Results with dialog.c.patch shows changes, but still we have negative numbers. They are in different places now though.
          Hide
          Mark Jansen
          added a comment -

          And this does not happen on windows when required is bigger than available?

          Show
          Mark Jansen
          added a comment - And this does not happen on windows when required is bigger than available?
          Hide
          Doug Lyons
          added a comment - - edited

          Windows XP with Limited Free Memory and then changing the Install to Drive F:\New is attached for reference. Now we see that Windows will show these numbers as Negative but show the size in MB. So maybe we just mask the high bit, do the conversion and then if the high bit is set then we add a minus sign in front of our result?
          Note that the CD Drive is not listed because you cannot install to it and ReactOS lists the CD drives which is another problem. Also, "Required Size" can never be negative.

          Show
          Doug Lyons
          added a comment - - edited Windows XP with Limited Free Memory and then changing the Install to Drive F:\New is attached for reference. Now we see that Windows will show these numbers as Negative but show the size in MB. So maybe we just mask the high bit, do the conversion and then if the high bit is set then we add a minus sign in front of our result? Note that the CD Drive is not listed because you cannot install to it and ReactOS lists the CD drives which is another problem. Also, "Required Size" can never be negative.
          Hide
          reactosfanboy
          added a comment -

          roughly 2,6GB which could be the expected number?

          For sure this is not the expected number. As you can see in the Windows tests the required size for MS ExcelViewer 2007 should be around 200MB at most. Also let's keep the unwanted CD-Rom-Drives as target aside for now.
          Fact is: "Required size calculation is often totally wrong" - even when it's sometimes not negative, we also have wrong positive numbers sometimes.
          Until now I could not observe any wrong calculation of "available space".

          Show
          reactosfanboy
          added a comment - roughly 2,6GB which could be the expected number? For sure this is not the expected number. As you can see in the Windows tests the required size for MS ExcelViewer 2007 should be around 200MB at most. Also let's keep the unwanted CD-Rom-Drives as target aside for now. Fact is: "Required size calculation is often totally wrong" - even when it's sometimes not negative, we also have wrong positive numbers sometimes. Until now I could not observe any wrong calculation of "available space".
          Hide
          Mark Jansen
          added a comment -

          This is what it looks like for me now:

          Show
          Mark Jansen
          added a comment - This is what it looks like for me now:
          Hide
          Mark Jansen
          added a comment -

          2.18 GB seems a bit excessive?

          Show
          Mark Jansen
          added a comment - 2.18 GB seems a bit excessive?
          Hide
          reactosfanboy
          added a comment -

          Yes, the estimation of 2.18GB in ros is much too excessive aka wrong.
          Instead of 2.18GB the setup in fact will require about additional 200MB on hard-disk.
          And that's around what a Windows 2003 Server shows as estimated value (193MB if I remember correctly).

          Show
          reactosfanboy
          added a comment - Yes, the estimation of 2.18GB in ros is much too excessive aka wrong. Instead of 2.18GB the setup in fact will require about additional 200MB on hard-disk. And that's around what a Windows 2003 Server shows as estimated value (193MB if I remember correctly).
          Hide
          Doug Lyons
          added a comment -

          If you look at ExcelViewerInstall73503.png you can see that in my ReactOS install the Required Bytes were 1.48 GB. This appears to come from estimates in the MSI Installer code and these estimates tend to vary widely in ReactOS somehow. This module appears to be Wine-synced to WineStaging-1.9.23. I wonder what Wine shows? I have no installs to be able to test this.

          Show
          Doug Lyons
          added a comment - If you look at ExcelViewerInstall73503.png you can see that in my ReactOS install the Required Bytes were 1.48 GB. This appears to come from estimates in the MSI Installer code and these estimates tend to vary widely in ReactOS somehow. This module appears to be Wine-synced to WineStaging-1.9.23. I wonder what Wine shows? I have no installs to be able to test this.
          Hide
          Doug Lyons
          added a comment -

          I created an apitest for StrFormatByteSizeW and it is attached. All 36 tests pass on WinXP, Win2K3, Win7, and ReactOS. It looks like this function is working correctly in ReactOS to me. Mark Jansen had asked about a test case for this I believe.

          Show
          Doug Lyons
          added a comment - I created an apitest for StrFormatByteSizeW and it is attached. All 36 tests pass on WinXP, Win2K3, Win7, and ReactOS. It looks like this function is working correctly in ReactOS to me. Mark Jansen had asked about a test case for this I believe.
          Hide
          Mark Jansen
          added a comment -

          Doug Lyons: Indeed I did, thanks!

          Show
          Mark Jansen
          added a comment - Doug Lyons : Indeed I did, thanks!
          Hide
          Mark Jansen
          added a comment - - edited

          heh.

          It's locale dependent :/

          StrFormatByteSizeW.c:40: Test failed: Expected L"1.00 KB" got L"1,00 KB"
          StrFormatByteSizeW.c:41: Test failed: Expected L"1.00 MB" got L"1,00 MB"
          StrFormatByteSizeW.c:42: Test failed: Expected L"1.00 GB" got L"1,00 GB"
          StrFormatByteSizeW.c:43: Test failed: Expected L"1.75 GB" got L"1,75 GB"
          StrFormatByteSizeW.c:44: Test failed: Expected L"2.00 GB" got L"2,00 GB"
          StrFormatByteSizeW.c:45: Test failed: Expected L"4.00 GB" got L"4,00 GB"
          StrFormatByteSizeW.c:46: Test failed: Expected L"1.00 TB" got L"1,00 TB"
          StrFormatByteSizeW.c:47: Test failed: Expected L"1.00 PB" got L"1,00 PB"
          StrFormatByteSizeW.c:48: Test failed: Expected L"1.00 EB" got L"1,00 EB"
          StrFormatByteSizeW.c:49: Test failed: Expected L"2.00 EB" got L"2,00 EB"
          StrFormatByteSizeW.c:50: Test failed: Expected L"4.00 EB" got L"4,00 EB"
          StrFormatByteSizeW.c:51: Test failed: Expected L"7.99 EB" got L"7,99 EB"
          

          Show
          Mark Jansen
          added a comment - - edited heh. It's locale dependent :/ StrFormatByteSizeW.c:40: Test failed: Expected L"1.00 KB" got L"1,00 KB" StrFormatByteSizeW.c:41: Test failed: Expected L"1.00 MB" got L"1,00 MB" StrFormatByteSizeW.c:42: Test failed: Expected L"1.00 GB" got L"1,00 GB" StrFormatByteSizeW.c:43: Test failed: Expected L"1.75 GB" got L"1,75 GB" StrFormatByteSizeW.c:44: Test failed: Expected L"2.00 GB" got L"2,00 GB" StrFormatByteSizeW.c:45: Test failed: Expected L"4.00 GB" got L"4,00 GB" StrFormatByteSizeW.c:46: Test failed: Expected L"1.00 TB" got L"1,00 TB" StrFormatByteSizeW.c:47: Test failed: Expected L"1.00 PB" got L"1,00 PB" StrFormatByteSizeW.c:48: Test failed: Expected L"1.00 EB" got L"1,00 EB" StrFormatByteSizeW.c:49: Test failed: Expected L"2.00 EB" got L"2,00 EB" StrFormatByteSizeW.c:50: Test failed: Expected L"4.00 EB" got L"4,00 EB" StrFormatByteSizeW.c:51: Test failed: Expected L"7.99 EB" got L"7,99 EB"
          Hide
          Doug Lyons
          added a comment -

          New apitest. Maybe a hack. What do you think?

          Show
          Doug Lyons
          added a comment - New apitest. Maybe a hack. What do you think?
          Hide
          victor martinez calvo
          added a comment -

          Looks as a nice hack
          Btw, probably you should check the last two items in the array KB,EB,etc in lowercase(iirc there are languages which could be using one of the letters in lowercase iirc).

          Show
          victor martinez calvo
          added a comment - Looks as a nice hack Btw, probably you should check the last two items in the array KB,EB,etc in lowercase(iirc there are languages which could be using one of the letters in lowercase iirc).
          Hide
          Mark Jansen
          added a comment -

          Doug Lyons: I have created a new issue to discuss this: CORE-12661

          Show
          Mark Jansen
          added a comment - Doug Lyons : I have created a new issue to discuss this: CORE-12661
          Hide
          Doug Lyons
          added a comment -

          The three attached MSI_Costing files were created on ReactOS using the English locale with +shell and +msi tracing turning on, so I believe that this issue is not just a German localization problem. As previously noted, the negative numbers are coming from the MSI Install section which can be seen with these logs. I added additional TRACE statements to see which items were responsible. You can add up the individual numbers and they match the final totals. Also, I have noticed that if you do the install right after a fresh ReactOS install the numbers will almost always be smaller than doing the install later. This seems to point to the possibility that the costing algorithm is returning memory addresses instead of the actual values. The MSI installer provides very inconsistent results for the Bytes Required (costing). All of this appears to be Wine-synced code. Luckily this does not affect the ability of the installer to work.

          Show
          Doug Lyons
          added a comment - The three attached MSI_Costing files were created on ReactOS using the English locale with +shell and +msi tracing turning on, so I believe that this issue is not just a German localization problem. As previously noted, the negative numbers are coming from the MSI Install section which can be seen with these logs. I added additional TRACE statements to see which items were responsible. You can add up the individual numbers and they match the final totals. Also, I have noticed that if you do the install right after a fresh ReactOS install the numbers will almost always be smaller than doing the install later. This seems to point to the possibility that the costing algorithm is returning memory addresses instead of the actual values. The MSI installer provides very inconsistent results for the Bytes Required (costing). All of this appears to be Wine-synced code. Luckily this does not affect the ability of the installer to work.

            People

            • Assignee:
              Bug Zilla
              Reporter:
              reactosfanboy
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: