iometer-devel — Dedicated for people who are contributing to the project / are interested in.

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[<jo...@ei...>]

As someone who hasn't been actively involved with iometer (or storage  
benchmarking/testing) for a while I know that there are several  
comments that I have heard over and over again.

1) Cross platform GUI - Daniel started looking at a java version  
several years ago but never followed up.  I have had luck running  
under wine in the past and was never interested in Mac.

2) performance degradation - The numbers that iometer was reporting  
dropped off a little compared to previous versions. I was never able  
to get hard numbers or revision numbers from anyone but this really  
points out a need for automated regressions on known hardware with  
multiple iometer versions.  I had these running in my lab for a while  
back in 2000/2001, but my last intel contact moved on and I drifted  
away and gave up my hardware empire ;-)

3) Tradeshow folks love the speedometer look, it is really one of the  
defining features and if we did another GUI it should be replicated.

Thanks to all of those who have continued development and it is nice  
to hear there are still people interested in helping out.

Joe


Quoting Robert Randall <rob...@gm...>:

> So IOMeter is old and dead?  We automate our IOMeter runs exclusively so
> I'm not sure what mean by lack of automate-ability.  IOMeter can be
> executed from a command line without user intervention.  In that case it
> feels a bit unnecessary to display a GUI at all.  It might be nice if it
> had a 'silent' mode to avoid the painting overhead.
>
> BR,
> Robert
>
>
> On Tue, Jan 14, 2014 at 3:28 PM, Carl Zwanzig <cp...@co...> wrote:
>
>>  Hi,
>>
>>
>>
>> Maybe  8 months ago I tried linux fio vs windows fio and the numbers
>> tracked quite closely (same version of fio, on a dual-boot system). At this
>> point, we really only use iometer if it?s demanded, otherwise we?re using
>> fio, iozone, or filebench. iometer was a good tool, but has suffered from
>> very deferred maintenance. The lack of automate-ability doesn?t help,
>> either.
>>
>>
>>
>> z!
>>
>>
>>
>> *From:* Robert Randall [mailto:rob...@gm...]
>> *Sent:* Tuesday, January 14, 2014 12:57 PM
>> *To:* Vedran Degoricija
>> *Cc:* iom...@li...
>> *Subject:* Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers
>> interested?
>>
>>
>>
>> FIO is all over the place.  The last time I reviewed their code they were
>> using the cygwin DLL as a shim for IO traffic (really bad idea).  The
>> latest versions use native calls.  I've not executed any 'bake off' number
>> in several months so I would have to collect some data and post it.
>>
>>
>>
>> Customers have informed me about the xperf vs. IOMeter discrepancies.  I
>> have not had time to collect independent data and confirm.  However, given
>> all of the changes introduced in Windows performance telemetry I don't find
>> this surprising.
>>
>> | rob...@gm...
>>
>
>
>
> --
> Robert Randall | rob...@gm...
>

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

So IOMeter is old and dead?  We automate our IOMeter runs exclusively so
I'm not sure what mean by lack of automate-ability.  IOMeter can be
executed from a command line without user intervention.  In that case it
feels a bit unnecessary to display a GUI at all.  It might be nice if it
had a 'silent' mode to avoid the painting overhead.

BR,
Robert


On Tue, Jan 14, 2014 at 3:28 PM, Carl Zwanzig <cp...@co...> wrote:

>  Hi,
>
>
>
> Maybe  8 months ago I tried linux fio vs windows fio and the numbers
> tracked quite closely (same version of fio, on a dual-boot system). At this
> point, we really only use iometer if it’s demanded, otherwise we’re using
> fio, iozone, or filebench. iometer was a good tool, but has suffered from
> very deferred maintenance. The lack of automate-ability doesn’t help,
> either.
>
>
>
> z!
>
>
>
> *From:* Robert Randall [mailto:rob...@gm...]
> *Sent:* Tuesday, January 14, 2014 12:57 PM
> *To:* Vedran Degoricija
> *Cc:* iom...@li...
> *Subject:* Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers
> interested?
>
>
>
> FIO is all over the place.  The last time I reviewed their code they were
> using the cygwin DLL as a shim for IO traffic (really bad idea).  The
> latest versions use native calls.  I've not executed any 'bake off' number
> in several months so I would have to collect some data and post it.
>
>
>
> Customers have informed me about the xperf vs. IOMeter discrepancies.  I
> have not had time to collect independent data and confirm.  However, given
> all of the changes introduced in Windows performance telemetry I don't find
> this surprising.
>
> | rob...@gm...
>



-- 
Robert Randall | rob...@gm...

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Carl Z. <cp...@co...>]

Hi,

Maybe  8 months ago I tried linux fio vs windows fio and the numbers tracked quite closely (same version of fio, on a dual-boot system). At this point, we really only use iometer if it's demanded, otherwise we're using fio, iozone, or filebench. iometer was a good tool, but has suffered from very deferred maintenance. The lack of automate-ability doesn't help, either.

z!

From: Robert Randall [mailto:rob...@gm...]
Sent: Tuesday, January 14, 2014 12:57 PM
To: Vedran Degoricija
Cc: iom...@li...
Subject: Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

FIO is all over the place.  The last time I reviewed their code they were using the cygwin DLL as a shim for IO traffic (really bad idea).  The latest versions use native calls.  I've not executed any 'bake off' number in several months so I would have to collect some data and post it.

Customers have informed me about the xperf vs. IOMeter discrepancies.  I have not had time to collect independent data and confirm.  However, given all of the changes introduced in Windows performance telemetry I don't find this surprising.
| rob...@gm...<mailto:rob...@gm...>

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

FIO is all over the place.  The last time I reviewed their code they were
using the cygwin DLL as a shim for IO traffic (really bad idea).  The
latest versions use native calls.  I've not executed any 'bake off' number
in several months so I would have to collect some data and post it.

Customers have informed me about the xperf vs. IOMeter discrepancies.  I
have not had time to collect independent data and confirm.  However, given
all of the changes introduced in Windows performance telemetry I don't find
this surprising.

BR,
Robert

On Tue, Jan 14, 2014 at 2:22 PM, Vedran Degoricija <ve...@ya...>wrote:

> Hi Randall,
>
> No arguments from me. Is there data that shows discrepancies between
> IOmeter and xperf today? And how do the FIO numbers compare?
>
> Cleanup of the MFC usage is welcome. I will safely speak for myself when I
> say I am no expert.
>
> The GUI re-write is a topic that has been discussed in the past. This
> opens up a big can of worms, but I am interested in going there. I'd let
> other folks comment.
>
> Thanks,
> Ved
>
>
>   On Tuesday, January 14, 2014 10:42 AM, Robert Randall <
> rob...@gm...> wrote:
>
> I did confirm that the multiple manager problem still exists.  When
> IOMeter opens a configuration file with multiple managers it spawns the
> first manager on the local host but does not spawn any additional managers
> and times out waiting for the additional managers to become available; i.e.
> connect to the IOMeter TCP port.
>
> Regards,
> Robert
>
>
> On Tue, Jan 14, 2014 at 10:10 AM, Vedran Degoricija <ve...@ya...>wrote:
>
> Thanks Robert. Let me review these.
>
> As far as only a single manager opening, I might have a fix. I'll need to
> recall what it is I actually fixed in this area-- it was about a year ago.
>
> Your offer for help is welcome. We've certainly been stagnant lately. Is
> there something in particular  that you are interested in?
>
> Thanks,
> Ved
>
>
>
>
>   On Tuesday, January 14, 2014 5:06 AM, Robert Randall <
> rob...@gm...> wrote:
>
>  I apologize for not copying the list on this message.  Please review the
> patch below and let me know if you need another maintainer <grin>.  I've
> been developing Windows apps since before there was a Windows kernel <my
> age is showing>.
>
> Best regards,
> Robert
>
> ---------- Forwarded message ----------
> From: *Robert Randall* <rob...@gm...>
> Date: Mon, Jan 13, 2014 at 7:04 PM
> Subject: Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
> To: "lefferts, john" <joh...@em...>
>
>
> Patch is below.  There are still a few issues I should clean up with
> regard to cleanly including the MFC headers.  I need to investigate one
> more internal bug report; loading .icf file with multiple managers results
> in the first manager being created other are not created.
>
>
> Index: src/GalileoApp.cpp
> ===================================================================
> --- src/GalileoApp.cpp (revision 141)
> +++ src/GalileoApp.cpp (working copy)
> @@ -122,6 +122,14 @@
>   delete login_port;
>  }
>
> +void CGalileoApp::CloseAllDocuments(BOOL bEndSession)
> +{
> + if (bEndSession)
> +   {
> +      m_wndStatusBar.DestroyWindow();
> +      m_wndToolBar.DestroyWindow();
> +   }
> +}
>
>  /////////////////////////////////////////////////////////////////////////////
>  // The one and only CGalileoApp object
>
> @@ -311,6 +319,8 @@
>
>  ///////////////////////////////////////////////////////////////////////////////
>  int CGalileoApp::ExitInstance()
>  {
> +   manager_list.RemoveAllManagers();
> +
>   delete[]m_pVersionString;
>   delete[]m_pVersionStringWithDebug;
>
> Index: src/GalileoApp.h
> ===================================================================
> --- src/GalileoApp.h (revision 141)
> +++ src/GalileoApp.h (working copy)
> @@ -130,6 +130,7 @@
>   virtual int ExitInstance();
>   virtual BOOL OnIdle(LONG lCount);
>   virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName);
> + virtual void CloseAllDocuments(BOOL bEndSession);
>   //}}AFX_VIRTUAL
>
>  // Implementation
> Index: src/GalileoView.cpp
> ===================================================================
> --- src/GalileoView.cpp (revision 141)
> +++ src/GalileoView.cpp (working copy)
> @@ -1180,6 +1180,7 @@
>  void CGalileoView::OnFileOpen()
>  {
>   BOOL flags[NumICFFlags];
> + CICFOpenDialog file_open_box; // open config file dialog box
>
>   // Show the custom file open dialog.
>   if (file_open_box.DoModal() == IDCANCEL)
> @@ -1202,6 +1203,7 @@
>  void CGalileoView::OnFileSave()
>  {
>   BOOL flags[NumICFFlags];
> + CICFSaveDialog file_save_box; // save config file dialog box
>
>   // Show the custom file save dialog.
>   if (file_save_box.DoModal() == IDCANCEL)
> Index: src/GalileoView.h
> ===================================================================
> --- src/GalileoView.h (revision 141)
> +++ src/GalileoView.h (working copy)
> @@ -182,8 +182,6 @@
>   CPropertySheet *m_pPropSheet;
>
>        protected:
> - CICFOpenDialog file_open_box; // open config file dialog box
> - CICFSaveDialog file_save_box; // save config file dialog box
>
>   // tracks whether parent frame has already been sized.
>   BOOL m_bSizedBefore;
> Index: src/ICFOpenDialog.cpp
> ===================================================================
> --- src/ICFOpenDialog.cpp (revision 141)
> +++ src/ICFOpenDialog.cpp (working copy)
> @@ -87,9 +87,10 @@
>
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFOpenDialog dialog
> -    CICFOpenDialog::CICFOpenDialog()
> -:  CFileDialog(TRUE, "icf", "", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +   CICFOpenDialog::CICFOpenDialog()
> +:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
> +            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +               NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFOpenDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/ICFSaveDialog.cpp
> ===================================================================
> --- src/ICFSaveDialog.cpp (revision 141)
> +++ src/ICFSaveDialog.cpp (working copy)
> @@ -88,8 +88,9 @@
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFSaveDialog dialog
>      CICFSaveDialog::CICFSaveDialog()
> -:  CFileDialog(FALSE, "icf", "iometer", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY |
> OFN_OVERWRITEPROMPT,
> +    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +        NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFSaveDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/IOCommon.h
> ===================================================================
> --- src/IOCommon.h (revision 141)
> +++ src/IOCommon.h (working copy)
> @@ -204,17 +204,21 @@
>  #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed
> here!
>   //#define VC_EXTRALEAN
>   //#pragma warning (disable: 4242)
> +#include "StdAfx.h"
> +//#define WIN32_LEAN_AND_MEAN 1
> +//#include <Windows.h>
> +//#include <windef.h>
>   #include <process.h>
>   #include <io.h>
>   #include <direct.h>
> - #include <afxwin.h>
> - #include <afxext.h>
> - #include <afxcmn.h>
> - #include <winioctl.h>
> +// #include <afxwin.h>
> +// #include <afxext.h>
> +// #include <afxcmn.h>
>   #include <iomanip>
>   #include <winperf.h>
>   #include <winreg.h>
> - #include <afxmt.h>
> + #include <winioctl.h>
> +// #include <afxmt.h>
>   #include <malloc.h>
>  #endif
>  //
> ----------------------------------------------------------------------------
> @@ -868,7 +872,7 @@
>   struct IOCQ {
>   CQ_Element      *element_list;
>   struct aiocb64 **aiocb_list;
> -#ifdef IOMTR_SETTING_LINUX_LIBAIO
> +#ifdef IOMTR_SETTING_LINUX_LIBAIO
>   struct iocb **iocb_list;
>          io_context_t io_ctx_id;
>          struct io_event *events;
> Index: src/IOPort.cpp
> ===================================================================
> --- src/IOPort.cpp (revision 141)
> +++ src/IOPort.cpp (working copy)
> @@ -81,6 +81,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
>  #include "GalileoApp.h"
>  #endif
>  #include "IOPort.h"
> Index: src/IOPortTCP.cpp
> ===================================================================
> --- src/IOPortTCP.cpp (revision 141)
> +++ src/IOPortTCP.cpp (working copy)
> @@ -89,7 +89,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> -#include <afx.h>
> +#include "StdAfx.h"
>  #endif
>
>  #include "IOPortTCP.h"
> Index: src/IOTarget.cpp
> ===================================================================
> --- src/IOTarget.cpp (revision 141)
> +++ src/IOTarget.cpp (working copy)
> @@ -109,6 +109,9 @@
>  #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
>   return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit));
>  #else
> +#ifdef _DEBUG
> + assert(limit > 0);
> +#endif
>   return (spec.random = A * spec.random + B) % limit;
>  #endif
>  }
> Index: src/IOTargetDisk.cpp
> ===================================================================
> --- src/IOTargetDisk.cpp (revision 141)
> +++ src/IOTargetDisk.cpp (working copy)
> @@ -1329,10 +1329,14 @@
>   // Loop through the I/O queue looking for idle slots.
>   for (i = 0; i < PREPARE_QDEPTH; i++) {
>   // Check to see if we've reached the end of the disk
> - if (spec.disk_info.maximum_size &&
> + // Windows debuggers lie when decoding spec.disk_info pushing
> + // values into local vars
> +            int dd_sector_size = spec.disk_info.sector_size;
> +            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size;
> +            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
> + if (dd_maximum_size &&
>      ((*prepare_offset + bytes) >
> -     ((spec.disk_info.starting_sector +
> -       (DWORDLONG) spec.disk_info.maximum_size) *
> spec.disk_info.sector_size))) {
> +     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
>   // A maximum disk size was specified by the user, and the next write
>   // would go past the specified maximum size.
>  #ifdef _DEBUG
> Index: src/IOTime.cpp
> ===================================================================
> --- src/IOTime.cpp (revision 141)
> +++ src/IOTime.cpp (working copy)
> @@ -92,6 +92,9 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> +#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
> +#endif
>  #include "IOCommon.h"
>
>  #if defined(IOMTR_OS_LINUX)
> Index: src/StdAfx.h
> ===================================================================
> --- src/StdAfx.h (revision 141)
> +++ src/StdAfx.h (working copy)
> @@ -58,11 +58,61 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> -#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
> +//#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
>
> -#include <afxwin.h> // MFC core and standard components
> +//#include <afxwin.h> // MFC core and standard components
>  //#include <afxext.h>         // MFC extensions
> +//#ifndef _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxcmn.h> // MFC support for Windows Common Controls
> +//#endif // _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxtempl.h>
> +
> +// stdafx.h : include file for standard system include files,
> +// or project specific include files that are used frequently,
> +// but are changed infrequently
> +
> +#pragma once
> +
> +#ifndef VC_EXTRALEAN
> +#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows
> headers
> +#endif
> +
> +#include "targetver.h"
> +
> +//#define _AFX_NO_OLE_SUPPORT 1
> +#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString
> constructors will be explicit
> +
> +// turns off MFC's hiding of some common and often safely ignored warning
> messages
> +#define _AFX_ALL_WARNINGS
> +
> +#include <afxwin.h>         // MFC core and standard components
> +#include <afxext.h>         // MFC extensions
> +
> +#ifndef _AFX_NO_OLE_SUPPORT
> +#include <afxdtctl.h>           // MFC support for Internet Explorer 4
> Common Controls
> +#endif
>  #ifndef _AFX_NO_AFXCMN_SUPPORT
> -#include <afxcmn.h> // MFC support for Windows Common Controls
> -#endif // _AFX_NO_AFXCMN_SUPPORT
> -//#include <afxtempl.h>
> +#include <afxcmn.h>             // MFC support for Windows Common Controls
> +#endif // _AFX_NO_AFXCMN_SUPPORT
> +
> +#include <afxcontrolbars.h>     // MFC support for ribbons and control
> bars
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +#ifdef _UNICODE
> +#if defined _M_IX86
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='x86' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#elif defined _M_X64
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#else
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
> +#endif
> +#endif
> +
> +
>
>
>
> On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...>wrote:
>
> I appreciate you valuable efforts.
> I think the developers would be better able to evaluate the technical
> merit of your changes if you take the extra time to construct a patch.
> Even a simple diff stream would be useful for a review.
>
> I have co-workers who complain about “crashes” when shutting-down a
> performance run—I wonder if you have addressed their issues.
>
> The SLN file under src/msvc9 says it was created with VS2008 (version 10)
> and I am using that.
> It has the same constructor.
>
> The developers have a comment that seems to indicate open-exclusive issues
> on reopen without prompt destruction of heap objects:
>
>       // This is key to getting the templates working properly and
> secondary opens to work at all?!
>       m_bVistaStyle = FALSE;
>
> I am interested in seeing your changes.
>
>
> *From:* Robert Randall [mailto:rob...@gm...]
> *Sent:* Monday, January 13, 2014 3:44 PM
> *To:* iom...@li...
> *Subject:* Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
>
> I also fixed a problem when running in batch mode.  The destruction
> sequence of Windows causes an exception.  The cheap fix is implementing a
> function in CGalileoApp.
>
> Regards,
> Robert
>
> On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <
> rob...@gm...> wrote:
>
> Hello,
>
> I've spent some time fixing a few simple problems with the latest version
> of MFC using the current trunk.  The CFileDialog constructors were being
> called incorrectly causing reference counting problems with COM.   The COM
> classes should not have been initialized in the first place.  Because the
> code was messing with m_bVistaStyle directly (not a good idea) it was
> causing the COM classes to be created but not destroyed which results in
> exceptions when running in the debugger and leaks resource when running a
> release build.
>
> I made these changes using VS 2012 and I don't have the tools to know if
> the CFileDialog constructor is compatible with previous releases of MFC.
>  I'm not sure how old a tool set is supported by the project when compiling
> on Windows.  Which versions of the compiler and MFC are supported?
>
> The constructor in the version of MFC I'm using is:
>
>
> CFileDialog(
>
>    BOOL bOpenFileDialog,
>
>    LPCTSTR lpszDefExt = NULL,
>
>    LPCTSTR lpszFileName = NULL,
>
>    DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>
>    LPCTSTR lpszFilter = NULL,
>
>    CWnd* pParentWnd = NULL,
>
>    DWORD dwSize = 0,
>
>    BOOL bVistaStyle = TRUE
>
> );
>
>
> I found one other minor problem.  When using a file on disk for testing
> the minimum Maximum Disk Size in sectors MUST be 128 or larger because of
> the code that IOTargetDisk::Prepare assumes that at least 64Kb will be
> written to the file.  A smaller value results in a divide by zero
> exception.  I'm not sure if Prepare should be fixed to handle smaller files
> or a minimum size should be enforced by the GUI.  Happy to make the fix
> either way.
>
>
> Let me know if you would like a patch for these changes.
>
> Best regards,
> Robert
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Iometer-devel mailing list
> Iom...@li...
> https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>


-- 
Robert Randall | rob...@gm...

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Vedran D. <ve...@ya...>]

Hi Randall,

No arguments from me. Is there data that shows discrepancies between IOmeter and xperf today? And how do the FIO numbers compare?

Cleanup of the MFC usage is welcome. I will safely speak for myself when I say I am no expert.

The GUI re-write is a topic that has been discussed in the past. This opens up a big can of worms, but I am interested in going there. I'd let other folks comment.

Thanks,
Ved



On Tuesday, January 14, 2014 10:42 AM, Robert Randall <rob...@gm...> wrote:
 
I did confirm that the multiple manager problem still exists.  When IOMeter opens a configuration file with multiple managers it spawns the first manager on the local host but does not spawn any additional managers and times out waiting for the additional managers to become available; i.e. connect to the IOMeter TCP port.
>
>
>Regards,
>Robert
>
>
>
>On Tue, Jan 14, 2014 at 10:10 AM, Vedran Degoricija <ve...@ya...> wrote:
>
>Thanks Robert. Let me review these.
>> 
>>As far as only a single manager opening, I might have a fix. I'll need to recall what it is I actually fixed in this area-- it was about a year ago. 
>> 
>>Your offer for help is welcome. We've certainly been stagnant lately. Is there something in particular  that you are interested in?
>> 
>>Thanks,
>>Ved
>> 
>> 
>>
>>
>>
>>On Tuesday, January 14, 2014 5:06 AM, Robert Randall <rob...@gm...> wrote:
>> 
>>I apologize for not copying the list on this message.  Please review the patch below and let me know if you need another maintainer <grin>.  I've been developing Windows apps since before there was a Windows kernel <my age is showing>.
>>>
>>>
>>>Best regards,
>>>Robert
>>>
>>>
>>>---------- Forwarded message ----------
>>>From: Robert Randall <rob...@gm...>
>>>Date: Mon, Jan 13, 2014 at 7:04 PM
>>>Subject: Re: [Iometer-devel] a couple fixes, are the maintainers interested?
>>>To: "lefferts, john" <joh...@em...>
>>>
>>>
>>>
>>>Patch is below.  There are still a few issues I should clean up with regard to cleanly including the MFC headers.  I need to investigate one more internal bug report; loading .icf file with multiple managers results in the first manager being created other are not created.
>>>
>>>
>>>
>>>
>>>Index: src/GalileoApp.cpp
>>>===================================================================
>>>--- src/GalileoApp.cpp(revision 141)
>>>+++ src/GalileoApp.cpp(working copy)
>>>@@ -122,6 +122,14 @@
>>> delete login_port;
>>> }
>>> 
>>>+void CGalileoApp::CloseAllDocuments(BOOL bEndSession) 
>>>+{
>>>+if (bEndSession)
>>>+   {
>>>+      m_wndStatusBar.DestroyWindow();
>>>+      m_wndToolBar.DestroyWindow();
>>>+   }
>>>+}
>>> /////////////////////////////////////////////////////////////////////////////
>>> // The one and only CGalileoApp object
>>> 
>>>@@ -311,6 +319,8 @@
>>> ///////////////////////////////////////////////////////////////////////////////
>>> int CGalileoApp::ExitInstance()
>>> {
>>>+   manager_list.RemoveAllManagers();
>>>+
>>> delete[]m_pVersionString;
>>> delete[]m_pVersionStringWithDebug;
>>> 
>>>Index: src/GalileoApp.h
>>>===================================================================
>>>--- src/GalileoApp.h(revision 141)
>>>+++ src/GalileoApp.h(working copy)
>>>@@ -130,6 +130,7 @@
>>> virtual int ExitInstance();
>>> virtual BOOL OnIdle(LONG lCount);
>>> virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName);
>>>+virtual void CloseAllDocuments(BOOL bEndSession); 
>>> //}}AFX_VIRTUAL
>>> 
>>> // Implementation
>>>Index: src/GalileoView.cpp
>>>===================================================================
>>>--- src/GalileoView.cpp(revision 141)
>>>+++ src/GalileoView.cpp(working copy)
>>>@@ -1180,6 +1180,7 @@
>>> void CGalileoView::OnFileOpen()
>>> {
>>> BOOL flags[NumICFFlags];
>>>+CICFOpenDialog file_open_box;// open config file dialog box
>>> 
>>> // Show the custom file open dialog.
>>> if (file_open_box.DoModal() == IDCANCEL)
>>>@@ -1202,6 +1203,7 @@
>>> void CGalileoView::OnFileSave()
>>> {
>>> BOOL flags[NumICFFlags];
>>>+CICFSaveDialog file_save_box;// save config file dialog box
>>> 
>>> // Show the custom file save dialog.
>>> if (file_save_box.DoModal() == IDCANCEL)
>>>Index: src/GalileoView.h
>>>===================================================================
>>>--- src/GalileoView.h(revision 141)
>>>+++ src/GalileoView.h(working copy)
>>>@@ -182,8 +182,6 @@
>>> CPropertySheet *m_pPropSheet;
>>> 
>>>       protected:
>>>-CICFOpenDialog file_open_box;// open config file dialog box
>>>-CICFSaveDialog file_save_box;// save config file dialog box
>>> 
>>> // tracks whether parent frame has already been sized.
>>> BOOL m_bSizedBefore;
>>>Index: src/ICFOpenDialog.cpp
>>>===================================================================
>>>--- src/ICFOpenDialog.cpp(revision 141)
>>>+++ src/ICFOpenDialog.cpp(working copy)
>>>@@ -87,9 +87,10 @@
>>> 
>>> /////////////////////////////////////////////////////////////////////////////
>>> // CICFOpenDialog dialog
>>>-    CICFOpenDialog::CICFOpenDialog()
>>>-:  CFileDialog(TRUE, "icf", "", NULL,
>>>-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||")
>>>+   CICFOpenDialog::CICFOpenDialog()
>>>+:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, 
>>>+            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||", 
>>>+               NULL, 0UL, FALSE)
>>> {
>>> CString title;
>>> char *buf;
>>>@@ -104,9 +105,6 @@
>>> 
>>> m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);
>>> 
>>>-// This is key to getting the templates working properly and secondary opens to work at all?!
>>>-m_bVistaStyle = FALSE;
>>>-
>>> //{{AFX_DATA_INIT(CICFOpenDialog)
>>> isCkTestSetup = TRUE;
>>> isCkResultsDisplay = TRUE;
>>>Index: src/ICFSaveDialog.cpp
>>>===================================================================
>>>--- src/ICFSaveDialog.cpp(revision 141)
>>>+++ src/ICFSaveDialog.cpp(working copy)
>>>@@ -88,8 +88,9 @@
>>> /////////////////////////////////////////////////////////////////////////////
>>> // CICFSaveDialog dialog
>>>     CICFSaveDialog::CICFSaveDialog()
>>>-:  CFileDialog(FALSE, "icf", "iometer", NULL,
>>>-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||")
>>>+:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>>>+    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||",
>>>+        NULL, 0UL, FALSE)
>>> {
>>> CString title;
>>> char *buf;
>>>@@ -104,9 +105,6 @@
>>> 
>>> m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS);
>>> 
>>>-// This is key to getting the templates working properly and secondary opens to work at all?!
>>>-m_bVistaStyle = FALSE;
>>>-
>>> //{{AFX_DATA_INIT(CICFSaveDialog)
>>> isCkTestSetup = TRUE;
>>> isCkResultsDisplay = TRUE;
>>>Index: src/IOCommon.h
>>>===================================================================
>>>--- src/IOCommon.h(revision 141)
>>>+++ src/IOCommon.h(working copy)
>>>@@ -204,17 +204,21 @@
>>> #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed here!
>>>  //#define VC_EXTRALEAN
>>>  //#pragma warning (disable: 4242)
>>>+#include "StdAfx.h"
>>>+//#define WIN32_LEAN_AND_MEAN 1
>>>+//#include <Windows.h>
>>>+//#include <windef.h>  
>>>  #include <process.h>
>>>  #include <io.h>
>>>  #include <direct.h>
>>>- #include <afxwin.h>
>>>- #include <afxext.h>
>>>- #include <afxcmn.h>
>>>- #include <winioctl.h>
>>>+// #include <afxwin.h>
>>>+// #include <afxext.h>
>>>+// #include <afxcmn.h>
>>>  #include <iomanip>
>>>  #include <winperf.h>
>>>  #include <winreg.h>
>>>- #include <afxmt.h>
>>>+ #include <winioctl.h>
>>>+// #include <afxmt.h>
>>>  #include <malloc.h>
>>> #endif
>>> // ----------------------------------------------------------------------------
>>>@@ -868,7 +872,7 @@
>>>  struct IOCQ {
>>> CQ_Element      *element_list;
>>> struct aiocb64 **aiocb_list;
>>>-#ifdef IOMTR_SETTING_LINUX_LIBAIO
>>>+#ifdef IOMTR_SETTING_LINUX_LIBAIO
>>> struct iocb **iocb_list;
>>>         io_context_t io_ctx_id;
>>>         struct io_event *events;
>>>Index: src/IOPort.cpp
>>>===================================================================
>>>--- src/IOPort.cpp(revision 141)
>>>+++ src/IOPort.cpp(working copy)
>>>@@ -81,6 +81,7 @@
>>> /* ######################################################################### */
>>> 
>>> #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>>>+#include "StdAfx.h"
>>> #include "GalileoApp.h"
>>> #endif
>>> #include "IOPort.h"
>>>Index: src/IOPortTCP.cpp
>>>===================================================================
>>>--- src/IOPortTCP.cpp(revision 141)
>>>+++ src/IOPortTCP.cpp(working copy)
>>>@@ -89,7 +89,7 @@
>>> /* ######################################################################### */
>>> 
>>> #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>>>-#include <afx.h>
>>>+#include "StdAfx.h"
>>> #endif
>>> 
>>> #include "IOPortTCP.h"
>>>Index: src/IOTarget.cpp
>>>===================================================================
>>>--- src/IOTarget.cpp(revision 141)
>>>+++ src/IOTarget.cpp(working copy)
>>>@@ -109,6 +109,9 @@
>>> #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
>>> return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit));
>>> #else
>>>+#ifdef _DEBUG
>>>+assert(limit > 0);
>>>+#endif
>>> return (spec.random = A * spec.random + B) % limit;
>>> #endif
>>> }
>>>Index: src/IOTargetDisk.cpp
>>>===================================================================
>>>--- src/IOTargetDisk.cpp(revision 141)
>>>+++ src/IOTargetDisk.cpp(working copy)
>>>@@ -1329,10 +1329,14 @@
>>> // Loop through the I/O queue looking for idle slots.
>>> for (i = 0; i < PREPARE_QDEPTH; i++) {
>>> // Check to see if we've reached the end of the disk
>>>-if (spec.disk_info.maximum_size &&
>>>+// Windows debuggers lie when decoding spec.disk_info pushing
>>>+// values into local vars
>>>+            int dd_sector_size = spec.disk_info.sector_size;
>>>+            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size;
>>>+            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
>>>+if (dd_maximum_size &&
>>>     ((*prepare_offset + bytes) >
>>>-     ((spec.disk_info.starting_sector +
>>>-       (DWORDLONG) spec.disk_info.maximum_size) * spec.disk_info.sector_size))) {
>>>+     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
>>> // A maximum disk size was specified by the user, and the next write 
>>> // would go past the specified maximum size.  
>>> #ifdef _DEBUG
>>>Index: src/IOTime.cpp
>>>===================================================================
>>>--- src/IOTime.cpp(revision 141)
>>>+++ src/IOTime.cpp(working copy)
>>>@@ -92,6 +92,9 @@
>>> /* ##                                                                     ## */
>>> /* ######################################################################### */
>>> 
>>>+#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>>>+#include "StdAfx.h"
>>>+#endif
>>> #include "IOCommon.h"
>>> 
>>> #if defined(IOMTR_OS_LINUX)
>>>Index: src/StdAfx.h
>>>===================================================================
>>>--- src/StdAfx.h(revision 141)
>>>+++ src/StdAfx.h(working copy)
>>>@@ -58,11 +58,61 @@
>>> /* ##                                                                     ## */
>>> /* ######################################################################### */
>>> 
>>>-#define VC_EXTRALEAN// Exclude rarely-used stuff from Windows headers
>>>+//#define VC_EXTRALEAN// Exclude rarely-used stuff from Windows headers
>>> 
>>>-#include <afxwin.h>// MFC core and standard components
>>>+//#include <afxwin.h>// MFC core and standard components
>>> //#include <afxext.h>         // MFC extensions
>>>+//#ifndef _AFX_NO_AFXCMN_SUPPORT
>>>+//#include <afxcmn.h>// MFC support for Windows Common Controls
>>>+//#endif// _AFX_NO_AFXCMN_SUPPORT
>>>+//#include <afxtempl.h>
>>>+
>>>+// stdafx.h : include file for standard system include files,
>>>+// or project specific include files that are used frequently,
>>>+// but are changed infrequently
>>>+
>>>+#pragma once
>>>+
>>>+#ifndef VC_EXTRALEAN
>>>+#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows headers
>>>+#endif
>>>+
>>>+#include "targetver.h"
>>>+
>>>+//#define _AFX_NO_OLE_SUPPORT 1
>>>+#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString constructors will be explicit
>>>+
>>>+// turns off MFC's hiding of some common and often safely ignored warning messages
>>>+#define _AFX_ALL_WARNINGS
>>>+
>>>+#include <afxwin.h>         // MFC core and standard components
>>>+#include <afxext.h>         // MFC extensions
>>>+
>>>+#ifndef _AFX_NO_OLE_SUPPORT
>>>+#include <afxdtctl.h>           // MFC support for Internet Explorer 4 Common Controls
>>>+#endif
>>> #ifndef _AFX_NO_AFXCMN_SUPPORT
>>>-#include <afxcmn.h>// MFC support for Windows Common Controls
>>>-#endif// _AFX_NO_AFXCMN_SUPPORT
>>>-//#include <afxtempl.h>
>>>+#include <afxcmn.h>             // MFC support for Windows Common Controls
>>>+#endif // _AFX_NO_AFXCMN_SUPPORT
>>>+
>>>+#include <afxcontrolbars.h>     // MFC support for ribbons and control bars
>>>+
>>>+
>>>+
>>>+
>>>+
>>>+
>>>+
>>>+
>>>+
>>>+#ifdef _UNICODE
>>>+#if defined _M_IX86
>>>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
>>>+#elif defined _M_X64
>>>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
>>>+#else
>>>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
>>>+#endif
>>>+#endif
>>>+
>>>+
>>>
>>>
>>>
>>>
>>>
>>>On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...> wrote:
>>>
>>>I appreciate you valuable efforts.
>>>>I think the developers would be better able to evaluate the technical merit of your changes if you take the extra time to construct a patch.
>>>>Even a simple diff stream would be useful for a review.
>>>> 
>>>>I have co-workers who complain about “crashes” when shutting-down a performance run—I wonder if you have addressed their issues.
>>>> 
>>>>The SLN file under src/msvc9 says it was created with VS2008 (version 10) and I am using that.
>>>>It has the same constructor.
>>>> 
>>>>The developers have a comment that seems to indicate open-exclusive issues on reopen without prompt destruction of heap objects:
>>>> 
>>>>      // This is key to getting the templates working properly and secondary opens to work at all?!
>>>>      m_bVistaStyle = FALSE;
>>>> 
>>>>I am interested in seeing your changes.
>>>> 
>>>> 
>>>>From:Robert Randall [mailto:rob...@gm...] 
>>>>Sent: Monday, January 13, 2014 3:44 PM
>>>>To: iom...@li...
>>>>Subject: Re: [Iometer-devel] a couple fixes, are the maintainers interested?
>>>> 
>>>>I also fixed a problem when running in batch mode.  The destruction sequence of Windows causes an exception.  The cheap fix is implementing a function in CGalileoApp.
>>>> 
>>>>Regards,
>>>>Robert
>>>> 
>>>>On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <rob...@gm...> wrote:
>>>> 
>>>>Hello,
>>>> 
>>>>I've spent some time fixing a few simple problems with the latest version of MFC using the current trunk.  The CFileDialog constructors were being called incorrectly causing reference counting problems with COM.   The COM classes should not have been initialized in the first place.  Because the code was messing with m_bVistaStyle directly (not a good idea) it was causing the COM classes to be created but not destroyed which results in exceptions when running in the debugger and leaks resource when running a release build.
>>>> 
>>>>I made these changes using VS 2012 and I don't have the tools to know if the CFileDialog constructor is compatible with previous releases of MFC.  I'm not sure how old a tool set is supported by the project when compiling on Windows.  Which versions of the compiler and MFC are supported?
>>>> 
>>>>The constructor in the version of MFC I'm using is:
>>>> 
>>>>CFileDialog(
>>>>   BOOL bOpenFileDialog,
>>>>   LPCTSTR lpszDefExt = NULL,
>>>>   LPCTSTR lpszFileName = NULL,
>>>>   DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>>>>   LPCTSTR lpszFilter = NULL,
>>>>   CWnd* pParentWnd = NULL,
>>>>   DWORD dwSize = 0,
>>>>   BOOL bVistaStyle = TRUE
>>>>);
>>>> 
>>>>I found one other minor problem.  When using a file on disk for testing the minimum Maximum Disk Size in sectors MUST be 128 or larger because of the code that IOTargetDisk::Prepare assumes that at least 64Kb will be written to the file.  A smaller value results in a divide by zero exception.  I'm not sure if Prepare should be fixed to handle smaller files or a minimum size should be enforced by the GUI.  Happy to make the fix either way.
>>>> 
>>>> 
>>>>Let me know if you would like a patch for these changes.
>>>> 
>>>>Best regards,
>>>>Robert
>>>> 
>>>>-- 
>>>>Robert Randall | rob...@gm... 
>>>>
>>>>
>>>>
>>>> 
>>>>-- 
>>>>Robert Randall | rob...@gm... 
>>>
>>>
>>>
>>>-- 
>>>Robert Randall | rob...@gm... 
>>>
>>>
>>>
>>>-- 
>>>Robert Randall | rob...@gm... 
>>>
>>>------------------------------------------------------------------------------
>>>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>Critical Workloads, Development Environments & Everything In Between.
>>>Get a Quote or Start a Free Trial Today. 
>>>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>_______________________________________________
>>>Iometer-devel mailing list
>>>Iom...@li...
>>>https://lists.sourceforge.net/lists/listinfo/iometer-devel
>>>
>>>
>>>
>
>
>
>-- 
>Robert Randall | rob...@gm... 
>
>

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

I did confirm that the multiple manager problem still exists.  When IOMeter
opens a configuration file with multiple managers it spawns the first
manager on the local host but does not spawn any additional managers and
times out waiting for the additional managers to become available; i.e.
connect to the IOMeter TCP port.

Regards,
Robert


On Tue, Jan 14, 2014 at 10:10 AM, Vedran Degoricija <ve...@ya...>wrote:

> Thanks Robert. Let me review these.
>
> As far as only a single manager opening, I might have a fix. I'll need to
> recall what it is I actually fixed in this area-- it was about a year ago.
>
> Your offer for help is welcome. We've certainly been stagnant lately. Is
> there something in particular  that you are interested in?
>
> Thanks,
> Ved
>
>
>
>
>   On Tuesday, January 14, 2014 5:06 AM, Robert Randall <
> rob...@gm...> wrote:
>
> I apologize for not copying the list on this message.  Please review the
> patch below and let me know if you need another maintainer <grin>.  I've
> been developing Windows apps since before there was a Windows kernel <my
> age is showing>.
>
> Best regards,
> Robert
>
> ---------- Forwarded message ----------
> From: *Robert Randall* <rob...@gm...>
> Date: Mon, Jan 13, 2014 at 7:04 PM
> Subject: Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
> To: "lefferts, john" <joh...@em...>
>
>
> Patch is below.  There are still a few issues I should clean up with
> regard to cleanly including the MFC headers.  I need to investigate one
> more internal bug report; loading .icf file with multiple managers results
> in the first manager being created other are not created.
>
>
> Index: src/GalileoApp.cpp
> ===================================================================
> --- src/GalileoApp.cpp (revision 141)
> +++ src/GalileoApp.cpp (working copy)
> @@ -122,6 +122,14 @@
>   delete login_port;
>  }
>
> +void CGalileoApp::CloseAllDocuments(BOOL bEndSession)
> +{
> + if (bEndSession)
> +   {
> +      m_wndStatusBar.DestroyWindow();
> +      m_wndToolBar.DestroyWindow();
> +   }
> +}
>
>  /////////////////////////////////////////////////////////////////////////////
>  // The one and only CGalileoApp object
>
> @@ -311,6 +319,8 @@
>
>  ///////////////////////////////////////////////////////////////////////////////
>  int CGalileoApp::ExitInstance()
>  {
> +   manager_list.RemoveAllManagers();
> +
>   delete[]m_pVersionString;
>   delete[]m_pVersionStringWithDebug;
>
> Index: src/GalileoApp.h
> ===================================================================
> --- src/GalileoApp.h (revision 141)
> +++ src/GalileoApp.h (working copy)
> @@ -130,6 +130,7 @@
>   virtual int ExitInstance();
>   virtual BOOL OnIdle(LONG lCount);
>   virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName);
> + virtual void CloseAllDocuments(BOOL bEndSession);
>   //}}AFX_VIRTUAL
>
>  // Implementation
> Index: src/GalileoView.cpp
> ===================================================================
> --- src/GalileoView.cpp (revision 141)
> +++ src/GalileoView.cpp (working copy)
> @@ -1180,6 +1180,7 @@
>  void CGalileoView::OnFileOpen()
>  {
>   BOOL flags[NumICFFlags];
> + CICFOpenDialog file_open_box; // open config file dialog box
>
>   // Show the custom file open dialog.
>   if (file_open_box.DoModal() == IDCANCEL)
> @@ -1202,6 +1203,7 @@
>  void CGalileoView::OnFileSave()
>  {
>   BOOL flags[NumICFFlags];
> + CICFSaveDialog file_save_box; // save config file dialog box
>
>   // Show the custom file save dialog.
>   if (file_save_box.DoModal() == IDCANCEL)
> Index: src/GalileoView.h
> ===================================================================
> --- src/GalileoView.h (revision 141)
> +++ src/GalileoView.h (working copy)
> @@ -182,8 +182,6 @@
>   CPropertySheet *m_pPropSheet;
>
>        protected:
> - CICFOpenDialog file_open_box; // open config file dialog box
> - CICFSaveDialog file_save_box; // save config file dialog box
>
>   // tracks whether parent frame has already been sized.
>   BOOL m_bSizedBefore;
> Index: src/ICFOpenDialog.cpp
> ===================================================================
> --- src/ICFOpenDialog.cpp (revision 141)
> +++ src/ICFOpenDialog.cpp (working copy)
> @@ -87,9 +87,10 @@
>
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFOpenDialog dialog
> -    CICFOpenDialog::CICFOpenDialog()
> -:  CFileDialog(TRUE, "icf", "", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +   CICFOpenDialog::CICFOpenDialog()
> +:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
> +            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +               NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFOpenDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/ICFSaveDialog.cpp
> ===================================================================
> --- src/ICFSaveDialog.cpp (revision 141)
> +++ src/ICFSaveDialog.cpp (working copy)
> @@ -88,8 +88,9 @@
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFSaveDialog dialog
>      CICFSaveDialog::CICFSaveDialog()
> -:  CFileDialog(FALSE, "icf", "iometer", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY |
> OFN_OVERWRITEPROMPT,
> +    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +        NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFSaveDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/IOCommon.h
> ===================================================================
> --- src/IOCommon.h (revision 141)
> +++ src/IOCommon.h (working copy)
> @@ -204,17 +204,21 @@
>  #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed
> here!
>   //#define VC_EXTRALEAN
>   //#pragma warning (disable: 4242)
> +#include "StdAfx.h"
> +//#define WIN32_LEAN_AND_MEAN 1
> +//#include <Windows.h>
> +//#include <windef.h>
>   #include <process.h>
>   #include <io.h>
>   #include <direct.h>
> - #include <afxwin.h>
> - #include <afxext.h>
> - #include <afxcmn.h>
> - #include <winioctl.h>
> +// #include <afxwin.h>
> +// #include <afxext.h>
> +// #include <afxcmn.h>
>   #include <iomanip>
>   #include <winperf.h>
>   #include <winreg.h>
> - #include <afxmt.h>
> + #include <winioctl.h>
> +// #include <afxmt.h>
>   #include <malloc.h>
>  #endif
>  //
> ----------------------------------------------------------------------------
> @@ -868,7 +872,7 @@
>   struct IOCQ {
>   CQ_Element      *element_list;
>   struct aiocb64 **aiocb_list;
> -#ifdef IOMTR_SETTING_LINUX_LIBAIO
> +#ifdef IOMTR_SETTING_LINUX_LIBAIO
>   struct iocb **iocb_list;
>          io_context_t io_ctx_id;
>          struct io_event *events;
> Index: src/IOPort.cpp
> ===================================================================
> --- src/IOPort.cpp (revision 141)
> +++ src/IOPort.cpp (working copy)
> @@ -81,6 +81,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
>  #include "GalileoApp.h"
>  #endif
>  #include "IOPort.h"
> Index: src/IOPortTCP.cpp
> ===================================================================
> --- src/IOPortTCP.cpp (revision 141)
> +++ src/IOPortTCP.cpp (working copy)
> @@ -89,7 +89,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> -#include <afx.h>
> +#include "StdAfx.h"
>  #endif
>
>  #include "IOPortTCP.h"
> Index: src/IOTarget.cpp
> ===================================================================
> --- src/IOTarget.cpp (revision 141)
> +++ src/IOTarget.cpp (working copy)
> @@ -109,6 +109,9 @@
>  #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
>   return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit));
>  #else
> +#ifdef _DEBUG
> + assert(limit > 0);
> +#endif
>   return (spec.random = A * spec.random + B) % limit;
>  #endif
>  }
> Index: src/IOTargetDisk.cpp
> ===================================================================
> --- src/IOTargetDisk.cpp (revision 141)
> +++ src/IOTargetDisk.cpp (working copy)
> @@ -1329,10 +1329,14 @@
>   // Loop through the I/O queue looking for idle slots.
>   for (i = 0; i < PREPARE_QDEPTH; i++) {
>   // Check to see if we've reached the end of the disk
> - if (spec.disk_info.maximum_size &&
> + // Windows debuggers lie when decoding spec.disk_info pushing
> + // values into local vars
> +            int dd_sector_size = spec.disk_info.sector_size;
> +            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size;
> +            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
> + if (dd_maximum_size &&
>      ((*prepare_offset + bytes) >
> -     ((spec.disk_info.starting_sector +
> -       (DWORDLONG) spec.disk_info.maximum_size) *
> spec.disk_info.sector_size))) {
> +     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
>   // A maximum disk size was specified by the user, and the next write
>   // would go past the specified maximum size.
>  #ifdef _DEBUG
> Index: src/IOTime.cpp
> ===================================================================
> --- src/IOTime.cpp (revision 141)
> +++ src/IOTime.cpp (working copy)
> @@ -92,6 +92,9 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> +#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
> +#endif
>  #include "IOCommon.h"
>
>  #if defined(IOMTR_OS_LINUX)
> Index: src/StdAfx.h
> ===================================================================
> --- src/StdAfx.h (revision 141)
> +++ src/StdAfx.h (working copy)
> @@ -58,11 +58,61 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> -#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
> +//#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
>
> -#include <afxwin.h> // MFC core and standard components
> +//#include <afxwin.h> // MFC core and standard components
>  //#include <afxext.h>         // MFC extensions
> +//#ifndef _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxcmn.h> // MFC support for Windows Common Controls
> +//#endif // _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxtempl.h>
> +
> +// stdafx.h : include file for standard system include files,
> +// or project specific include files that are used frequently,
> +// but are changed infrequently
> +
> +#pragma once
> +
> +#ifndef VC_EXTRALEAN
> +#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows
> headers
> +#endif
> +
> +#include "targetver.h"
> +
> +//#define _AFX_NO_OLE_SUPPORT 1
> +#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString
> constructors will be explicit
> +
> +// turns off MFC's hiding of some common and often safely ignored warning
> messages
> +#define _AFX_ALL_WARNINGS
> +
> +#include <afxwin.h>         // MFC core and standard components
> +#include <afxext.h>         // MFC extensions
> +
> +#ifndef _AFX_NO_OLE_SUPPORT
> +#include <afxdtctl.h>           // MFC support for Internet Explorer 4
> Common Controls
> +#endif
>  #ifndef _AFX_NO_AFXCMN_SUPPORT
> -#include <afxcmn.h> // MFC support for Windows Common Controls
> -#endif // _AFX_NO_AFXCMN_SUPPORT
> -//#include <afxtempl.h>
> +#include <afxcmn.h>             // MFC support for Windows Common Controls
> +#endif // _AFX_NO_AFXCMN_SUPPORT
> +
> +#include <afxcontrolbars.h>     // MFC support for ribbons and control
> bars
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +#ifdef _UNICODE
> +#if defined _M_IX86
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='x86' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#elif defined _M_X64
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#else
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
> +#endif
> +#endif
> +
> +
>
>
>
> On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...>wrote:
>
> I appreciate you valuable efforts.
> I think the developers would be better able to evaluate the technical
> merit of your changes if you take the extra time to construct a patch.
> Even a simple diff stream would be useful for a review.
>
> I have co-workers who complain about “crashes” when shutting-down a
> performance run—I wonder if you have addressed their issues.
>
> The SLN file under src/msvc9 says it was created with VS2008 (version 10)
> and I am using that.
> It has the same constructor.
>
> The developers have a comment that seems to indicate open-exclusive issues
> on reopen without prompt destruction of heap objects:
>
>       // This is key to getting the templates working properly and
> secondary opens to work at all?!
>       m_bVistaStyle = FALSE;
>
> I am interested in seeing your changes.
>
>
> *From:* Robert Randall [mailto:rob...@gm...]
> *Sent:* Monday, January 13, 2014 3:44 PM
> *To:* iom...@li...
> *Subject:* Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
>
> I also fixed a problem when running in batch mode.  The destruction
> sequence of Windows causes an exception.  The cheap fix is implementing a
> function in CGalileoApp.
>
> Regards,
> Robert
>
> On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <
> rob...@gm...> wrote:
>
> Hello,
>
> I've spent some time fixing a few simple problems with the latest version
> of MFC using the current trunk.  The CFileDialog constructors were being
> called incorrectly causing reference counting problems with COM.   The COM
> classes should not have been initialized in the first place.  Because the
> code was messing with m_bVistaStyle directly (not a good idea) it was
> causing the COM classes to be created but not destroyed which results in
> exceptions when running in the debugger and leaks resource when running a
> release build.
>
> I made these changes using VS 2012 and I don't have the tools to know if
> the CFileDialog constructor is compatible with previous releases of MFC.
>  I'm not sure how old a tool set is supported by the project when compiling
> on Windows.  Which versions of the compiler and MFC are supported?
>
> The constructor in the version of MFC I'm using is:
>
>
> CFileDialog(
>
>    BOOL bOpenFileDialog,
>
>    LPCTSTR lpszDefExt = NULL,
>
>    LPCTSTR lpszFileName = NULL,
>
>    DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>
>    LPCTSTR lpszFilter = NULL,
>
>    CWnd* pParentWnd = NULL,
>
>    DWORD dwSize = 0,
>
>    BOOL bVistaStyle = TRUE
>
> );
>
>
> I found one other minor problem.  When using a file on disk for testing
> the minimum Maximum Disk Size in sectors MUST be 128 or larger because of
> the code that IOTargetDisk::Prepare assumes that at least 64Kb will be
> written to the file.  A smaller value results in a divide by zero
> exception.  I'm not sure if Prepare should be fixed to handle smaller files
> or a minimum size should be enforced by the GUI.  Happy to make the fix
> either way.
>
>
> Let me know if you would like a patch for these changes.
>
> Best regards,
> Robert
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Iometer-devel mailing list
> Iom...@li...
> https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>


-- 
Robert Randall | rob...@gm...

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

Hi Ved,

Well, for Windows, there is a bit of code cleanup that could occur just to
make both the GUI and Dynamo a bit safer.  The include uses for MFC are a
bit messy which can create unexpected crashes, etc.  We get pushed to use
FIO but our customers do not use FIO they use IOMeter so we stick to that.
 I've not had time to review the IO and measurement code on Windows but it
feels like that is old enough to perhaps warrant a review for updates
and/or weak spots.  It would be best if the data collected by IOMeter on
Windows matched what xperf collects.  The very knowledgeable customers use
their own IO generation utilities which mimic the traffic of their apps and
they rely on xperf for measurement.  Demonstrating that the two match or
nearly match feel like it would be beneficial.

Past that, the entire GUI of IOMeter is a bit out of date and a bit
confusing to the disk io tester.  Have you thought about a new GUI?  Might
even be cross platform GUI, something like wxWidgets.  That would give
Linux and Mac OS users a GUI.

Just my $0.02.

Best regards,
Robert


On Tue, Jan 14, 2014 at 10:10 AM, Vedran Degoricija <ve...@ya...>wrote:

> Thanks Robert. Let me review these.
>
> As far as only a single manager opening, I might have a fix. I'll need to
> recall what it is I actually fixed in this area-- it was about a year ago.
>
> Your offer for help is welcome. We've certainly been stagnant lately. Is
> there something in particular  that you are interested in?
>
> Thanks,
> Ved
>
>
>
>
>   On Tuesday, January 14, 2014 5:06 AM, Robert Randall <
> rob...@gm...> wrote:
>
> I apologize for not copying the list on this message.  Please review the
> patch below and let me know if you need another maintainer <grin>.  I've
> been developing Windows apps since before there was a Windows kernel <my
> age is showing>.
>
> Best regards,
> Robert
>
> ---------- Forwarded message ----------
> From: *Robert Randall* <rob...@gm...>
> Date: Mon, Jan 13, 2014 at 7:04 PM
> Subject: Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
> To: "lefferts, john" <joh...@em...>
>
>
> Patch is below.  There are still a few issues I should clean up with
> regard to cleanly including the MFC headers.  I need to investigate one
> more internal bug report; loading .icf file with multiple managers results
> in the first manager being created other are not created.
>
>
> Index: src/GalileoApp.cpp
> ===================================================================
> --- src/GalileoApp.cpp (revision 141)
> +++ src/GalileoApp.cpp (working copy)
> @@ -122,6 +122,14 @@
>   delete login_port;
>  }
>
> +void CGalileoApp::CloseAllDocuments(BOOL bEndSession)
> +{
> + if (bEndSession)
> +   {
> +      m_wndStatusBar.DestroyWindow();
> +      m_wndToolBar.DestroyWindow();
> +   }
> +}
>
>  /////////////////////////////////////////////////////////////////////////////
>  // The one and only CGalileoApp object
>
> @@ -311,6 +319,8 @@
>
>  ///////////////////////////////////////////////////////////////////////////////
>  int CGalileoApp::ExitInstance()
>  {
> +   manager_list.RemoveAllManagers();
> +
>   delete[]m_pVersionString;
>   delete[]m_pVersionStringWithDebug;
>
> Index: src/GalileoApp.h
> ===================================================================
> --- src/GalileoApp.h (revision 141)
> +++ src/GalileoApp.h (working copy)
> @@ -130,6 +130,7 @@
>   virtual int ExitInstance();
>   virtual BOOL OnIdle(LONG lCount);
>   virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName);
> + virtual void CloseAllDocuments(BOOL bEndSession);
>   //}}AFX_VIRTUAL
>
>  // Implementation
> Index: src/GalileoView.cpp
> ===================================================================
> --- src/GalileoView.cpp (revision 141)
> +++ src/GalileoView.cpp (working copy)
> @@ -1180,6 +1180,7 @@
>  void CGalileoView::OnFileOpen()
>  {
>   BOOL flags[NumICFFlags];
> + CICFOpenDialog file_open_box; // open config file dialog box
>
>   // Show the custom file open dialog.
>   if (file_open_box.DoModal() == IDCANCEL)
> @@ -1202,6 +1203,7 @@
>  void CGalileoView::OnFileSave()
>  {
>   BOOL flags[NumICFFlags];
> + CICFSaveDialog file_save_box; // save config file dialog box
>
>   // Show the custom file save dialog.
>   if (file_save_box.DoModal() == IDCANCEL)
> Index: src/GalileoView.h
> ===================================================================
> --- src/GalileoView.h (revision 141)
> +++ src/GalileoView.h (working copy)
> @@ -182,8 +182,6 @@
>   CPropertySheet *m_pPropSheet;
>
>        protected:
> - CICFOpenDialog file_open_box; // open config file dialog box
> - CICFSaveDialog file_save_box; // save config file dialog box
>
>   // tracks whether parent frame has already been sized.
>   BOOL m_bSizedBefore;
> Index: src/ICFOpenDialog.cpp
> ===================================================================
> --- src/ICFOpenDialog.cpp (revision 141)
> +++ src/ICFOpenDialog.cpp (working copy)
> @@ -87,9 +87,10 @@
>
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFOpenDialog dialog
> -    CICFOpenDialog::CICFOpenDialog()
> -:  CFileDialog(TRUE, "icf", "", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +   CICFOpenDialog::CICFOpenDialog()
> +:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
> +            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +               NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFOpenDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/ICFSaveDialog.cpp
> ===================================================================
> --- src/ICFSaveDialog.cpp (revision 141)
> +++ src/ICFSaveDialog.cpp (working copy)
> @@ -88,8 +88,9 @@
>
>  /////////////////////////////////////////////////////////////////////////////
>  // CICFSaveDialog dialog
>      CICFSaveDialog::CICFSaveDialog()
> -:  CFileDialog(FALSE, "icf", "iometer", NULL,
> -    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||")
> +:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY |
> OFN_OVERWRITEPROMPT,
> +    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
> (*.txt)|*.txt|All Files (*.*)|*.*||",
> +        NULL, 0UL, FALSE)
>  {
>   CString title;
>   char *buf;
> @@ -104,9 +105,6 @@
>
>   m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS);
>
> - // This is key to getting the templates working properly and secondary
> opens to work at all?!
> - m_bVistaStyle = FALSE;
> -
>   //{{AFX_DATA_INIT(CICFSaveDialog)
>   isCkTestSetup = TRUE;
>   isCkResultsDisplay = TRUE;
> Index: src/IOCommon.h
> ===================================================================
> --- src/IOCommon.h (revision 141)
> +++ src/IOCommon.h (working copy)
> @@ -204,17 +204,21 @@
>  #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed
> here!
>   //#define VC_EXTRALEAN
>   //#pragma warning (disable: 4242)
> +#include "StdAfx.h"
> +//#define WIN32_LEAN_AND_MEAN 1
> +//#include <Windows.h>
> +//#include <windef.h>
>   #include <process.h>
>   #include <io.h>
>   #include <direct.h>
> - #include <afxwin.h>
> - #include <afxext.h>
> - #include <afxcmn.h>
> - #include <winioctl.h>
> +// #include <afxwin.h>
> +// #include <afxext.h>
> +// #include <afxcmn.h>
>   #include <iomanip>
>   #include <winperf.h>
>   #include <winreg.h>
> - #include <afxmt.h>
> + #include <winioctl.h>
> +// #include <afxmt.h>
>   #include <malloc.h>
>  #endif
>  //
> ----------------------------------------------------------------------------
> @@ -868,7 +872,7 @@
>   struct IOCQ {
>   CQ_Element      *element_list;
>   struct aiocb64 **aiocb_list;
> -#ifdef IOMTR_SETTING_LINUX_LIBAIO
> +#ifdef IOMTR_SETTING_LINUX_LIBAIO
>   struct iocb **iocb_list;
>          io_context_t io_ctx_id;
>          struct io_event *events;
> Index: src/IOPort.cpp
> ===================================================================
> --- src/IOPort.cpp (revision 141)
> +++ src/IOPort.cpp (working copy)
> @@ -81,6 +81,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
>  #include "GalileoApp.h"
>  #endif
>  #include "IOPort.h"
> Index: src/IOPortTCP.cpp
> ===================================================================
> --- src/IOPortTCP.cpp (revision 141)
> +++ src/IOPortTCP.cpp (working copy)
> @@ -89,7 +89,7 @@
>  /*
> ######################################################################### */
>
>  #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> -#include <afx.h>
> +#include "StdAfx.h"
>  #endif
>
>  #include "IOPortTCP.h"
> Index: src/IOTarget.cpp
> ===================================================================
> --- src/IOTarget.cpp (revision 141)
> +++ src/IOTarget.cpp (working copy)
> @@ -109,6 +109,9 @@
>  #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
>   return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit));
>  #else
> +#ifdef _DEBUG
> + assert(limit > 0);
> +#endif
>   return (spec.random = A * spec.random + B) % limit;
>  #endif
>  }
> Index: src/IOTargetDisk.cpp
> ===================================================================
> --- src/IOTargetDisk.cpp (revision 141)
> +++ src/IOTargetDisk.cpp (working copy)
> @@ -1329,10 +1329,14 @@
>   // Loop through the I/O queue looking for idle slots.
>   for (i = 0; i < PREPARE_QDEPTH; i++) {
>   // Check to see if we've reached the end of the disk
> - if (spec.disk_info.maximum_size &&
> + // Windows debuggers lie when decoding spec.disk_info pushing
> + // values into local vars
> +            int dd_sector_size = spec.disk_info.sector_size;
> +            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size;
> +            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
> + if (dd_maximum_size &&
>      ((*prepare_offset + bytes) >
> -     ((spec.disk_info.starting_sector +
> -       (DWORDLONG) spec.disk_info.maximum_size) *
> spec.disk_info.sector_size))) {
> +     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
>   // A maximum disk size was specified by the user, and the next write
>   // would go past the specified maximum size.
>  #ifdef _DEBUG
> Index: src/IOTime.cpp
> ===================================================================
> --- src/IOTime.cpp (revision 141)
> +++ src/IOTime.cpp (working copy)
> @@ -92,6 +92,9 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> +#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
> +#include "StdAfx.h"
> +#endif
>  #include "IOCommon.h"
>
>  #if defined(IOMTR_OS_LINUX)
> Index: src/StdAfx.h
> ===================================================================
> --- src/StdAfx.h (revision 141)
> +++ src/StdAfx.h (working copy)
> @@ -58,11 +58,61 @@
>  /* ##
> ## */
>  /*
> ######################################################################### */
>
> -#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
> +//#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
>
> -#include <afxwin.h> // MFC core and standard components
> +//#include <afxwin.h> // MFC core and standard components
>  //#include <afxext.h>         // MFC extensions
> +//#ifndef _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxcmn.h> // MFC support for Windows Common Controls
> +//#endif // _AFX_NO_AFXCMN_SUPPORT
> +//#include <afxtempl.h>
> +
> +// stdafx.h : include file for standard system include files,
> +// or project specific include files that are used frequently,
> +// but are changed infrequently
> +
> +#pragma once
> +
> +#ifndef VC_EXTRALEAN
> +#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows
> headers
> +#endif
> +
> +#include "targetver.h"
> +
> +//#define _AFX_NO_OLE_SUPPORT 1
> +#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString
> constructors will be explicit
> +
> +// turns off MFC's hiding of some common and often safely ignored warning
> messages
> +#define _AFX_ALL_WARNINGS
> +
> +#include <afxwin.h>         // MFC core and standard components
> +#include <afxext.h>         // MFC extensions
> +
> +#ifndef _AFX_NO_OLE_SUPPORT
> +#include <afxdtctl.h>           // MFC support for Internet Explorer 4
> Common Controls
> +#endif
>  #ifndef _AFX_NO_AFXCMN_SUPPORT
> -#include <afxcmn.h> // MFC support for Windows Common Controls
> -#endif // _AFX_NO_AFXCMN_SUPPORT
> -//#include <afxtempl.h>
> +#include <afxcmn.h>             // MFC support for Windows Common Controls
> +#endif // _AFX_NO_AFXCMN_SUPPORT
> +
> +#include <afxcontrolbars.h>     // MFC support for ribbons and control
> bars
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +#ifdef _UNICODE
> +#if defined _M_IX86
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='x86' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#elif defined _M_X64
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'
> language='*'\"")
> +#else
> +#pragma comment(linker,"/manifestdependency:\"type='win32'
> name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
> processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
> +#endif
> +#endif
> +
> +
>
>
>
> On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...>wrote:
>
> I appreciate you valuable efforts.
> I think the developers would be better able to evaluate the technical
> merit of your changes if you take the extra time to construct a patch.
> Even a simple diff stream would be useful for a review.
>
> I have co-workers who complain about “crashes” when shutting-down a
> performance run—I wonder if you have addressed their issues.
>
> The SLN file under src/msvc9 says it was created with VS2008 (version 10)
> and I am using that.
> It has the same constructor.
>
> The developers have a comment that seems to indicate open-exclusive issues
> on reopen without prompt destruction of heap objects:
>
>       // This is key to getting the templates working properly and
> secondary opens to work at all?!
>       m_bVistaStyle = FALSE;
>
> I am interested in seeing your changes.
>
>
> *From:* Robert Randall [mailto:rob...@gm...]
> *Sent:* Monday, January 13, 2014 3:44 PM
> *To:* iom...@li...
> *Subject:* Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
>
> I also fixed a problem when running in batch mode.  The destruction
> sequence of Windows causes an exception.  The cheap fix is implementing a
> function in CGalileoApp.
>
> Regards,
> Robert
>
> On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <
> rob...@gm...> wrote:
>
> Hello,
>
> I've spent some time fixing a few simple problems with the latest version
> of MFC using the current trunk.  The CFileDialog constructors were being
> called incorrectly causing reference counting problems with COM.   The COM
> classes should not have been initialized in the first place.  Because the
> code was messing with m_bVistaStyle directly (not a good idea) it was
> causing the COM classes to be created but not destroyed which results in
> exceptions when running in the debugger and leaks resource when running a
> release build.
>
> I made these changes using VS 2012 and I don't have the tools to know if
> the CFileDialog constructor is compatible with previous releases of MFC.
>  I'm not sure how old a tool set is supported by the project when compiling
> on Windows.  Which versions of the compiler and MFC are supported?
>
> The constructor in the version of MFC I'm using is:
>
>
> CFileDialog(
>
>    BOOL bOpenFileDialog,
>
>    LPCTSTR lpszDefExt = NULL,
>
>    LPCTSTR lpszFileName = NULL,
>
>    DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>
>    LPCTSTR lpszFilter = NULL,
>
>    CWnd* pParentWnd = NULL,
>
>    DWORD dwSize = 0,
>
>    BOOL bVistaStyle = TRUE
>
> );
>
>
> I found one other minor problem.  When using a file on disk for testing
> the minimum Maximum Disk Size in sectors MUST be 128 or larger because of
> the code that IOTargetDisk::Prepare assumes that at least 64Kb will be
> written to the file.  A smaller value results in a divide by zero
> exception.  I'm not sure if Prepare should be fixed to handle smaller files
> or a minimum size should be enforced by the GUI.  Happy to make the fix
> either way.
>
>
> Let me know if you would like a patch for these changes.
>
> Best regards,
> Robert
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Iometer-devel mailing list
> Iom...@li...
> https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>


-- 
Robert Randall | rob...@gm...

Re: [Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Vedran D. <ve...@ya...>]

Thanks Robert. Let me review these.
 
As far as only a single manager opening, I might have a fix. I'll need to recall what it is I actually fixed in this area-- it was about a year ago. 
 
Your offer for help is welcome. We've certainly been stagnant lately. Is there something in particular  that you are interested in?
 
Thanks,
Ved
 
 



On Tuesday, January 14, 2014 5:06 AM, Robert Randall <rob...@gm...> wrote:
  
I apologize for not copying the list on this message.  Please review the patch below and let me know if you need another maintainer <grin>.  I've been developing Windows apps since before there was a Windows kernel <my age is showing>.
>
>
>Best regards,
>Robert
>
>
>---------- Forwarded message ----------
>From: Robert Randall <rob...@gm...>
>Date: Mon, Jan 13, 2014 at 7:04 PM
>Subject: Re: [Iometer-devel] a couple fixes, are the maintainers interested?
>To: "lefferts, john" <joh...@em...>
>
>
>
>Patch is below.  There are still a few issues I should clean up with regard to cleanly including the MFC headers.  I need to investigate one more internal bug report; loading .icf file with multiple managers results in the first manager being created other are not created. 
>
>
>
>
>Index: src/GalileoApp.cpp
>===================================================================
>--- src/GalileoApp.cpp(revision 141) 
>+++ src/GalileoApp.cpp(working copy)
>@@ -122,6 +122,14 @@
> delete login_port;
> }
>
>+void CGalileoApp::CloseAllDocuments(BOOL bEndSession) 
>+{
>+if (bEndSession)
>+   {
>+      m_wndStatusBar.DestroyWindow();
>+      m_wndToolBar.DestroyWindow();
>+   }
>+}
> /////////////////////////////////////////////////////////////////////////////
> // The one and only CGalileoApp object
>
>@@ -311,6 +319,8 @@
> ///////////////////////////////////////////////////////////////////////////////
> int CGalileoApp::ExitInstance()
> {
>+   manager_list.RemoveAllManagers(); 
>+
> delete[]m_pVersionString;
> delete[]m_pVersionStringWithDebug;
>
>Index: src/GalileoApp.h 
>===================================================================
>--- src/GalileoApp.h(revision 141)
>+++ src/GalileoApp.h(working copy) 
>@@ -130,6 +130,7 @@
> virtual int ExitInstance();
> virtual BOOL OnIdle(LONG lCount);
> virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName); 
>+virtual void CloseAllDocuments(BOOL bEndSession); 
> //}}AFX_VIRTUAL
>
> // Implementation 
>Index: src/GalileoView.cpp
>===================================================================
>--- src/GalileoView.cpp(revision 141)
>+++ src/GalileoView.cpp(working copy) 
>@@ -1180,6 +1180,7 @@
> void CGalileoView::OnFileOpen()
> {
> BOOL flags[NumICFFlags];
>+CICFOpenDialog file_open_box;// open config file dialog box 
>
> // Show the custom file open dialog.
> if (file_open_box.DoModal() == IDCANCEL)
>@@ -1202,6 +1203,7 @@ 
> void CGalileoView::OnFileSave()
> {
> BOOL flags[NumICFFlags];
>+CICFSaveDialog file_save_box;// save config file dialog box 
>
> // Show the custom file save dialog.
> if (file_save_box.DoModal() == IDCANCEL)
>Index: src/GalileoView.h 
>===================================================================
>--- src/GalileoView.h(revision 141)
>+++ src/GalileoView.h(working copy) 
>@@ -182,8 +182,6 @@
> CPropertySheet *m_pPropSheet;
>
>       protected:
>-CICFOpenDialog file_open_box;// open config file dialog box 
>-CICFSaveDialog file_save_box;// save config file dialog box
>
> // tracks whether parent frame has already been sized. 
> BOOL m_bSizedBefore;
>Index: src/ICFOpenDialog.cpp
>===================================================================
>--- src/ICFOpenDialog.cpp(revision 141) 
>+++ src/ICFOpenDialog.cpp(working copy)
>@@ -87,9 +87,10 @@
>
> ///////////////////////////////////////////////////////////////////////////// 
> // CICFOpenDialog dialog
>-    CICFOpenDialog::CICFOpenDialog()
>-:  CFileDialog(TRUE, "icf", "", NULL,
>-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||") 
>+   CICFOpenDialog::CICFOpenDialog()
>+:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, 
>+            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||",  
>+               NULL, 0UL, FALSE)
> {
> CString title;
> char *buf;
>@@ -104,9 +105,6 @@ 
> 
> m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);
>
>-// This is key to getting the templates working properly and secondary opens to work at all?! 
>-m_bVistaStyle = FALSE;
>-
> //{{AFX_DATA_INIT(CICFOpenDialog) 
> isCkTestSetup = TRUE;
> isCkResultsDisplay = TRUE;
>Index: src/ICFSaveDialog.cpp
>=================================================================== 
>--- src/ICFSaveDialog.cpp(revision 141)
>+++ src/ICFSaveDialog.cpp(working copy)
>@@ -88,8 +88,9 @@ 
> /////////////////////////////////////////////////////////////////////////////
> // CICFSaveDialog dialog
>     CICFSaveDialog::CICFSaveDialog()
>-:  CFileDialog(FALSE, "icf", "iometer", NULL, 
>-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||")
>+:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, 
>+    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files (*.txt)|*.txt|All Files (*.*)|*.*||",
>+        NULL, 0UL, FALSE)
> { 
> CString title;
> char *buf;
>@@ -104,9 +105,6 @@
>
> m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS); 
>
>-// This is key to getting the templates working properly and secondary opens to work at all?!
>-m_bVistaStyle = FALSE; 
>-
> //{{AFX_DATA_INIT(CICFSaveDialog)
> isCkTestSetup = TRUE;
> isCkResultsDisplay = TRUE; 
>Index: src/IOCommon.h
>===================================================================
>--- src/IOCommon.h(revision 141)
>+++ src/IOCommon.h(working copy) 
>@@ -204,17 +204,21 @@
> #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed here!
>  //#define VC_EXTRALEAN
>  //#pragma warning (disable: 4242)
>+#include "StdAfx.h" 
>+//#define WIN32_LEAN_AND_MEAN 1
>+//#include <Windows.h>
>+//#include <windef.h>  
>  #include <process.h>
>  #include <io.h>
>  #include <direct.h> 
>- #include <afxwin.h>
>- #include <afxext.h>
>- #include <afxcmn.h>
>- #include <winioctl.h>
>+// #include <afxwin.h>
>+// #include <afxext.h> 
>+// #include <afxcmn.h>
>  #include <iomanip>
>  #include <winperf.h>
>  #include <winreg.h>
>- #include <afxmt.h>
>+ #include <winioctl.h> 
>+// #include <afxmt.h>
>  #include <malloc.h>
> #endif
> // ----------------------------------------------------------------------------
>@@ -868,7 +872,7 @@
>  struct IOCQ {
> CQ_Element      *element_list;
> struct aiocb64 **aiocb_list;
>-#ifdef IOMTR_SETTING_LINUX_LIBAIO 
>+#ifdef IOMTR_SETTING_LINUX_LIBAIO
> struct iocb **iocb_list;
>         io_context_t io_ctx_id;
>         struct io_event *events;
>Index: src/IOPort.cpp 
>===================================================================
>--- src/IOPort.cpp(revision 141)
>+++ src/IOPort.cpp(working copy) 
>@@ -81,6 +81,7 @@
> /* ######################################################################### */
>
> #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>+#include "StdAfx.h" 
> #include "GalileoApp.h"
> #endif
> #include "IOPort.h"
>Index: src/IOPortTCP.cpp
>===================================================================
>--- src/IOPortTCP.cpp(revision 141)
>+++ src/IOPortTCP.cpp(working copy)
>@@ -89,7 +89,7 @@
> /* ######################################################################### */ 
>
> #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>-#include <afx.h>
>+#include "StdAfx.h"
> #endif
>
> #include "IOPortTCP.h" 
>Index: src/IOTarget.cpp
>===================================================================
>--- src/IOTarget.cpp(revision 141)
>+++ src/IOTarget.cpp(working copy) 
>@@ -109,6 +109,9 @@
> #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
> return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit)); 
> #else
>+#ifdef _DEBUG
>+assert(limit > 0);
>+#endif
> return (spec.random = A * spec.random + B) % limit; 
> #endif
> }
>Index: src/IOTargetDisk.cpp
>===================================================================
>--- src/IOTargetDisk.cpp(revision 141) 
>+++ src/IOTargetDisk.cpp(working copy)
>@@ -1329,10 +1329,14 @@
> // Loop through the I/O queue looking for idle slots. 
> for (i = 0; i < PREPARE_QDEPTH; i++) {
> // Check to see if we've reached the end of the disk
>-if (spec.disk_info.maximum_size &&
>+// Windows debuggers lie when decoding spec.disk_info pushing 
>+// values into local vars
>+            int dd_sector_size = spec.disk_info.sector_size;
>+            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size; 
>+            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
>+if (dd_maximum_size &&
>     ((*prepare_offset + bytes) > 
>-     ((spec.disk_info.starting_sector +
>-       (DWORDLONG) spec.disk_info.maximum_size) * spec.disk_info.sector_size))) { 
>+     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
> // A maximum disk size was specified by the user, and the next write  
> // would go past the specified maximum size.  
> #ifdef _DEBUG
>Index: src/IOTime.cpp
>=================================================================== 
>--- src/IOTime.cpp(revision 141)
>+++ src/IOTime.cpp(working copy)
>@@ -92,6 +92,9 @@
> /* ##                                                                     ## */ 
> /* ######################################################################### */
>
>+#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
>+#include "StdAfx.h"
>+#endif 
> #include "IOCommon.h"
>
> #if defined(IOMTR_OS_LINUX)
>Index: src/StdAfx.h
>===================================================================
>--- src/StdAfx.h(revision 141) 
>+++ src/StdAfx.h(working copy)
>@@ -58,11 +58,61 @@
> /* ##                                                                     ## */
> /* ######################################################################### */ 
>
>-#define VC_EXTRALEAN// Exclude rarely-used stuff from Windows headers
>+//#define VC_EXTRALEAN// Exclude rarely-used stuff from Windows headers 
>
>-#include <afxwin.h>// MFC core and standard components
>+//#include <afxwin.h>// MFC core and standard components 
> //#include <afxext.h>         // MFC extensions
>+//#ifndef _AFX_NO_AFXCMN_SUPPORT
>+//#include <afxcmn.h>// MFC support for Windows Common Controls 
>+//#endif// _AFX_NO_AFXCMN_SUPPORT
>+//#include <afxtempl.h>
>+
>+// stdafx.h : include file for standard system include files, 
>+// or project specific include files that are used frequently,
>+// but are changed infrequently
>+
>+#pragma once
>+
>+#ifndef VC_EXTRALEAN
>+#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows headers 
>+#endif
>+
>+#include "targetver.h"
>+
>+//#define _AFX_NO_OLE_SUPPORT 1
>+#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString constructors will be explicit 
>+
>+// turns off MFC's hiding of some common and often safely ignored warning messages
>+#define _AFX_ALL_WARNINGS
>+
>+#include <afxwin.h>         // MFC core and standard components 
>+#include <afxext.h>         // MFC extensions
>+
>+#ifndef _AFX_NO_OLE_SUPPORT
>+#include <afxdtctl.h>           // MFC support for Internet Explorer 4 Common Controls
>+#endif
> #ifndef _AFX_NO_AFXCMN_SUPPORT
>-#include <afxcmn.h>// MFC support for Windows Common Controls
>-#endif// _AFX_NO_AFXCMN_SUPPORT 
>-//#include <afxtempl.h>
>+#include <afxcmn.h>             // MFC support for Windows Common Controls
>+#endif // _AFX_NO_AFXCMN_SUPPORT
>+
>+#include <afxcontrolbars.h>     // MFC support for ribbons and control bars 
>+
>+
>+
>+
>+
>+
>+
>+
>+
>+#ifdef _UNICODE
>+#if defined _M_IX86
>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"") 
>+#elif defined _M_X64
>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"") 
>+#else
>+#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"") 
>+#endif
>+#endif
>+
>+
>
>
>
>
>
>On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...> wrote:
>
>I appreciate you valuable efforts. 
>>I think the developers would be better able to evaluate the technical merit of your changes if you take the extra time to construct a patch. 
>>Even a simple diff stream would be useful for a review.
>> 
>>I have co-workers who complain about “crashes” when shutting-down a performance run—I wonder if you have addressed their issues. 
>> 
>>The SLN file under src/msvc9 says it was created with VS2008 (version 10) and I am using that. 
>>It has the same constructor.
>>  
>>The developers have a comment that seems to indicate open-exclusive issues on reopen without prompt destruction of heap objects: 
>> 
>>      // This is key to getting the templates working properly and secondary opens to work at all?! 
>>      m_bVistaStyle = FALSE;
>>  
>>I am interested in seeing your changes.
>>  
>> 
>>From:Robert Randall [mailto:rob...@gm...] 
>>Sent: Monday, January 13, 2014 3:44 PM
>>To: iom...@li...
>>Subject: Re: [Iometer-devel] a couple fixes, are the maintainers interested? 
>> 
>>I also fixed a problem when running in batch mode.  The destruction sequence of Windows causes an exception.  The cheap fix is implementing a function in CGalileoApp. 
>> 
>>Regards,
>>Robert
>>  
>>On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <rob...@gm...> wrote:
>> 
>>Hello,
>> 
>>I've spent some time fixing a few simple problems with the latest version of MFC using the current trunk.  The CFileDialog constructors were being called incorrectly causing reference counting problems with COM.   The COM classes should not have been initialized in the first place.  Because the code was messing with m_bVistaStyle directly (not a good idea) it was causing the COM classes to be created but not destroyed which results in exceptions when running in the debugger and leaks resource when running a release build. 
>> 
>>I made these changes using VS 2012 and I don't have the tools to know if the CFileDialog constructor is compatible with previous releases of MFC.  I'm not sure how old a tool set is supported by the project when compiling on Windows.  Which versions of the compiler and MFC are supported? 
>> 
>>The constructor in the version of MFC I'm using is:
>> 
>>CFileDialog(
>>   BOOL bOpenFileDialog,
>>   LPCTSTR lpszDefExt = NULL,
>>   LPCTSTR lpszFileName = NULL,
>>   DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, 
>>   LPCTSTR lpszFilter = NULL,
>>   CWnd* pParentWnd = NULL,
>>   DWORD dwSize = 0,
>>   BOOL bVistaStyle = TRUE
>>); 
>> 
>>I found one other minor problem.  When using a file on disk for testing the minimum Maximum Disk Size in sectors MUST be 128 or larger because of the code that IOTargetDisk::Prepare assumes that at least 64Kb will be written to the file.  A smaller value results in a divide by zero exception.  I'm not sure if Prepare should be fixed to handle smaller files or a minimum size should be enforced by the GUI.  Happy to make the fix either way. 
>> 
>> 
>>Let me know if you would like a patch for these changes.
>> 
>>Best regards,
>>Robert
>>  
>>-- 
>>Robert Randall | rob...@gm...  
>>
>>
>>
>> 
>>-- 
>>Robert Randall | rob...@gm...  
>
>
>
>-- 
>Robert Randall | rob...@gm...  
>
>
>
>-- 
>Robert Randall | rob...@gm... 
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today. 
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>_______________________________________________
>Iometer-devel mailing list
>Iom...@li...
>https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>     

[Iometer-devel] Fwd: a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

I apologize for not copying the list on this message.  Please review the
patch below and let me know if you need another maintainer <grin>.  I've
been developing Windows apps since before there was a Windows kernel <my
age is showing>.

Best regards,
Robert

---------- Forwarded message ----------
From: Robert Randall <rob...@gm...>
Date: Mon, Jan 13, 2014 at 7:04 PM
Subject: Re: [Iometer-devel] a couple fixes, are the maintainers interested?
To: "lefferts, john" <joh...@em...>


Patch is below.  There are still a few issues I should clean up with regard
to cleanly including the MFC headers.  I need to investigate one more
internal bug report; loading .icf file with multiple managers results in
the first manager being created other are not created.


Index: src/GalileoApp.cpp
===================================================================
--- src/GalileoApp.cpp (revision 141)
+++ src/GalileoApp.cpp (working copy)
@@ -122,6 +122,14 @@
  delete login_port;
 }

+void CGalileoApp::CloseAllDocuments(BOOL bEndSession)
+{
+ if (bEndSession)
+   {
+      m_wndStatusBar.DestroyWindow();
+      m_wndToolBar.DestroyWindow();
+   }
+}
 /////////////////////////////////////////////////////////////////////////////
 // The one and only CGalileoApp object

@@ -311,6 +319,8 @@
 ///////////////////////////////////////////////////////////////////////////////
 int CGalileoApp::ExitInstance()
 {
+   manager_list.RemoveAllManagers();
+
  delete[]m_pVersionString;
  delete[]m_pVersionStringWithDebug;

Index: src/GalileoApp.h
===================================================================
--- src/GalileoApp.h (revision 141)
+++ src/GalileoApp.h (working copy)
@@ -130,6 +130,7 @@
  virtual int ExitInstance();
  virtual BOOL OnIdle(LONG lCount);
  virtual CDocument *OpenDocumentFile(LPCTSTR lpszFileName);
+ virtual void CloseAllDocuments(BOOL bEndSession);
  //}}AFX_VIRTUAL

 // Implementation
Index: src/GalileoView.cpp
===================================================================
--- src/GalileoView.cpp (revision 141)
+++ src/GalileoView.cpp (working copy)
@@ -1180,6 +1180,7 @@
 void CGalileoView::OnFileOpen()
 {
  BOOL flags[NumICFFlags];
+ CICFOpenDialog file_open_box; // open config file dialog box

  // Show the custom file open dialog.
  if (file_open_box.DoModal() == IDCANCEL)
@@ -1202,6 +1203,7 @@
 void CGalileoView::OnFileSave()
 {
  BOOL flags[NumICFFlags];
+ CICFSaveDialog file_save_box; // save config file dialog box

  // Show the custom file save dialog.
  if (file_save_box.DoModal() == IDCANCEL)
Index: src/GalileoView.h
===================================================================
--- src/GalileoView.h (revision 141)
+++ src/GalileoView.h (working copy)
@@ -182,8 +182,6 @@
  CPropertySheet *m_pPropSheet;

       protected:
- CICFOpenDialog file_open_box; // open config file dialog box
- CICFSaveDialog file_save_box; // save config file dialog box

  // tracks whether parent frame has already been sized.
  BOOL m_bSizedBefore;
Index: src/ICFOpenDialog.cpp
===================================================================
--- src/ICFOpenDialog.cpp (revision 141)
+++ src/ICFOpenDialog.cpp (working copy)
@@ -87,9 +87,10 @@

 /////////////////////////////////////////////////////////////////////////////
 // CICFOpenDialog dialog
-    CICFOpenDialog::CICFOpenDialog()
-:  CFileDialog(TRUE, "icf", "", NULL,
-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
(*.txt)|*.txt|All Files (*.*)|*.*||")
+   CICFOpenDialog::CICFOpenDialog()
+:  CFileDialog(TRUE, "icf", NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
+            "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
(*.txt)|*.txt|All Files (*.*)|*.*||",
+               NULL, 0UL, FALSE)
 {
  CString title;
  char *buf;
@@ -104,9 +105,6 @@

  m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILEOPEN_OPTS);

- // This is key to getting the templates working properly and secondary
opens to work at all?!
- m_bVistaStyle = FALSE;
-
  //{{AFX_DATA_INIT(CICFOpenDialog)
  isCkTestSetup = TRUE;
  isCkResultsDisplay = TRUE;
Index: src/ICFSaveDialog.cpp
===================================================================
--- src/ICFSaveDialog.cpp (revision 141)
+++ src/ICFSaveDialog.cpp (working copy)
@@ -88,8 +88,9 @@
 /////////////////////////////////////////////////////////////////////////////
 // CICFSaveDialog dialog
     CICFSaveDialog::CICFSaveDialog()
-:  CFileDialog(FALSE, "icf", "iometer", NULL,
-    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
(*.txt)|*.txt|All Files (*.*)|*.*||")
+:  CFileDialog(FALSE, "icf", "iometer",  OFN_HIDEREADONLY |
OFN_OVERWRITEPROMPT,
+    "Iometer Configuration Files (*.icf)|*.icf|" "Text Files
(*.txt)|*.txt|All Files (*.*)|*.*||",
+        NULL, 0UL, FALSE)
 {
  CString title;
  char *buf;
@@ -104,9 +105,6 @@

  m_ofn.lpTemplateName = MAKEINTRESOURCE(IDD_FILESAVE_OPTS);

- // This is key to getting the templates working properly and secondary
opens to work at all?!
- m_bVistaStyle = FALSE;
-
  //{{AFX_DATA_INIT(CICFSaveDialog)
  isCkTestSetup = TRUE;
  isCkResultsDisplay = TRUE;
Index: src/IOCommon.h
===================================================================
--- src/IOCommon.h (revision 141)
+++ src/IOCommon.h (working copy)
@@ -204,17 +204,21 @@
 #if defined(IOMTR_OSFAMILY_WINDOWS)   // Only first, because it is needed
here!
  //#define VC_EXTRALEAN
  //#pragma warning (disable: 4242)
+#include "StdAfx.h"
+//#define WIN32_LEAN_AND_MEAN 1
+//#include <Windows.h>
+//#include <windef.h>
  #include <process.h>
  #include <io.h>
  #include <direct.h>
- #include <afxwin.h>
- #include <afxext.h>
- #include <afxcmn.h>
- #include <winioctl.h>
+// #include <afxwin.h>
+// #include <afxext.h>
+// #include <afxcmn.h>
  #include <iomanip>
  #include <winperf.h>
  #include <winreg.h>
- #include <afxmt.h>
+ #include <winioctl.h>
+// #include <afxmt.h>
  #include <malloc.h>
 #endif
 //
----------------------------------------------------------------------------
@@ -868,7 +872,7 @@
  struct IOCQ {
  CQ_Element      *element_list;
  struct aiocb64 **aiocb_list;
-#ifdef IOMTR_SETTING_LINUX_LIBAIO
+#ifdef IOMTR_SETTING_LINUX_LIBAIO
  struct iocb **iocb_list;
         io_context_t io_ctx_id;
         struct io_event *events;
Index: src/IOPort.cpp
===================================================================
--- src/IOPort.cpp (revision 141)
+++ src/IOPort.cpp (working copy)
@@ -81,6 +81,7 @@
 /*
######################################################################### */

 #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
+#include "StdAfx.h"
 #include "GalileoApp.h"
 #endif
 #include "IOPort.h"
Index: src/IOPortTCP.cpp
===================================================================
--- src/IOPortTCP.cpp (revision 141)
+++ src/IOPortTCP.cpp (working copy)
@@ -89,7 +89,7 @@
 /*
######################################################################### */

 #if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
-#include <afx.h>
+#include "StdAfx.h"
 #endif

 #include "IOPortTCP.h"
Index: src/IOTarget.cpp
===================================================================
--- src/IOTarget.cpp (revision 141)
+++ src/IOTarget.cpp (working copy)
@@ -109,6 +109,9 @@
 #if defined(IOMTR_OSFAMILY_UNIX) && defined(WORKAROUND_MOD_BUG)
  return ((DWORDLONG)fmodl(spec.random = A * spec.random + B, limit));
 #else
+#ifdef _DEBUG
+ assert(limit > 0);
+#endif
  return (spec.random = A * spec.random + B) % limit;
 #endif
 }
Index: src/IOTargetDisk.cpp
===================================================================
--- src/IOTargetDisk.cpp (revision 141)
+++ src/IOTargetDisk.cpp (working copy)
@@ -1329,10 +1329,14 @@
  // Loop through the I/O queue looking for idle slots.
  for (i = 0; i < PREPARE_QDEPTH; i++) {
  // Check to see if we've reached the end of the disk
- if (spec.disk_info.maximum_size &&
+ // Windows debuggers lie when decoding spec.disk_info pushing
+ // values into local vars
+            int dd_sector_size = spec.disk_info.sector_size;
+            ULONGLONG dd_maximum_size = spec.disk_info.maximum_size;
+            ULONGLONG dd_starting_sector = spec.disk_info.starting_sector;
+ if (dd_maximum_size &&
     ((*prepare_offset + bytes) >
-     ((spec.disk_info.starting_sector +
-       (DWORDLONG) spec.disk_info.maximum_size) *
spec.disk_info.sector_size))) {
+     ((dd_starting_sector + dd_maximum_size) * dd_sector_size))) {
  // A maximum disk size was specified by the user, and the next write
  // would go past the specified maximum size.
 #ifdef _DEBUG
Index: src/IOTime.cpp
===================================================================
--- src/IOTime.cpp (revision 141)
+++ src/IOTime.cpp (working copy)
@@ -92,6 +92,9 @@
 /* ##
## */
 /*
######################################################################### */

+#if defined(IOMTR_OS_WIN32) || defined(IOMTR_OS_WIN64)
+#include "StdAfx.h"
+#endif
 #include "IOCommon.h"

 #if defined(IOMTR_OS_LINUX)
Index: src/StdAfx.h
===================================================================
--- src/StdAfx.h (revision 141)
+++ src/StdAfx.h (working copy)
@@ -58,11 +58,61 @@
 /* ##
## */
 /*
######################################################################### */

-#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
+//#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers

-#include <afxwin.h> // MFC core and standard components
+//#include <afxwin.h> // MFC core and standard components
 //#include <afxext.h>         // MFC extensions
+//#ifndef _AFX_NO_AFXCMN_SUPPORT
+//#include <afxcmn.h> // MFC support for Windows Common Controls
+//#endif // _AFX_NO_AFXCMN_SUPPORT
+//#include <afxtempl.h>
+
+// stdafx.h : include file for standard system include files,
+// or project specific include files that are used frequently,
+// but are changed infrequently
+
+#pragma once
+
+#ifndef VC_EXTRALEAN
+#define VC_EXTRALEAN            // Exclude rarely-used stuff from Windows
headers
+#endif
+
+#include "targetver.h"
+
+//#define _AFX_NO_OLE_SUPPORT 1
+#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS      // some CString
constructors will be explicit
+
+// turns off MFC's hiding of some common and often safely ignored warning
messages
+#define _AFX_ALL_WARNINGS
+
+#include <afxwin.h>         // MFC core and standard components
+#include <afxext.h>         // MFC extensions
+
+#ifndef _AFX_NO_OLE_SUPPORT
+#include <afxdtctl.h>           // MFC support for Internet Explorer 4
Common Controls
+#endif
 #ifndef _AFX_NO_AFXCMN_SUPPORT
-#include <afxcmn.h> // MFC support for Windows Common Controls
-#endif // _AFX_NO_AFXCMN_SUPPORT
-//#include <afxtempl.h>
+#include <afxcmn.h>             // MFC support for Windows Common Controls
+#endif // _AFX_NO_AFXCMN_SUPPORT
+
+#include <afxcontrolbars.h>     // MFC support for ribbons and control bars
+
+
+
+
+
+
+
+
+
+#ifdef _UNICODE
+#if defined _M_IX86
+#pragma comment(linker,"/manifestdependency:\"type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='x86' publicKeyToken='6595b64144ccf1df'
language='*'\"")
+#elif defined _M_X64
+#pragma comment(linker,"/manifestdependency:\"type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df'
language='*'\"")
+#else
+#pragma comment(linker,"/manifestdependency:\"type='win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
+#endif
+#endif
+
+



On Mon, Jan 13, 2014 at 3:10 PM, lefferts, john <joh...@em...>wrote:

> I appreciate you valuable efforts.
>
> I think the developers would be better able to evaluate the technical
> merit of your changes if you take the extra time to construct a patch.
>
> Even a simple diff stream would be useful for a review.
>
>
>
> I have co-workers who complain about “crashes” when shutting-down a
> performance run—I wonder if you have addressed their issues.
>
>
>
> The SLN file under src/msvc9 says it was created with VS2008 (version 10)
> and I am using that.
>
> It has the same constructor.
>
>
>
> The developers have a comment that seems to indicate open-exclusive issues
> on reopen without prompt destruction of heap objects:
>
>
>
>       // This is key to getting the templates working properly and
> secondary opens to work at all?!
>
>       m_bVistaStyle = FALSE;
>
>
>
> I am interested in seeing your changes.
>
>
>
>
>
> *From:* Robert Randall [mailto:rob...@gm...]
> *Sent:* Monday, January 13, 2014 3:44 PM
> *To:* iom...@li...
> *Subject:* Re: [Iometer-devel] a couple fixes, are the maintainers
> interested?
>
>
>
> I also fixed a problem when running in batch mode.  The destruction
> sequence of Windows causes an exception.  The cheap fix is implementing a
> function in CGalileoApp.
>
>
>
> Regards,
>
> Robert
>
>
>
> On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <
> rob...@gm...> wrote:
>
>
>
> Hello,
>
>
>
> I've spent some time fixing a few simple problems with the latest version
> of MFC using the current trunk.  The CFileDialog constructors were being
> called incorrectly causing reference counting problems with COM.   The COM
> classes should not have been initialized in the first place.  Because the
> code was messing with m_bVistaStyle directly (not a good idea) it was
> causing the COM classes to be created but not destroyed which results in
> exceptions when running in the debugger and leaks resource when running a
> release build.
>
>
>
> I made these changes using VS 2012 and I don't have the tools to know if
> the CFileDialog constructor is compatible with previous releases of MFC.
>  I'm not sure how old a tool set is supported by the project when compiling
> on Windows.  Which versions of the compiler and MFC are supported?
>
>
>
> The constructor in the version of MFC I'm using is:
>
>
>
> CFileDialog(
>
>    BOOL bOpenFileDialog,
>
>    LPCTSTR lpszDefExt = NULL,
>
>    LPCTSTR lpszFileName = NULL,
>
>    DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>
>    LPCTSTR lpszFilter = NULL,
>
>    CWnd* pParentWnd = NULL,
>
>    DWORD dwSize = 0,
>
>    BOOL bVistaStyle = TRUE
>
> );
>
>
>
> I found one other minor problem.  When using a file on disk for testing
> the minimum Maximum Disk Size in sectors MUST be 128 or larger because of
> the code that IOTargetDisk::Prepare assumes that at least 64Kb will be
> written to the file.  A smaller value results in a divide by zero
> exception.  I'm not sure if Prepare should be fixed to handle smaller files
> or a minimum size should be enforced by the GUI.  Happy to make the fix
> either way.
>
>
>
>
>
> Let me know if you would like a patch for these changes.
>
>
>
> Best regards,
>
> Robert
>
>
>
> --
> Robert Randall | rob...@gm...
>
>
>
>
>
> --
> Robert Randall | rob...@gm...
>



-- 
Robert Randall | rob...@gm...



-- 
Robert Randall | rob...@gm...

Re: [Iometer-devel] a couple fixes, are the maintainers interested?

[Vedran D. <ve...@ya...>]

Hi Robert,
 Thanks for the feedback. You can blame me for that one...

I recall that a move from MFC 6.x to newer libs in VS 20xx caused a much worse bug to appear where the open and save dialogs were formatted incorrectly. I eventually used the bVistaStyle setting to address it. Are you saying that the reference to m_bVistaStyle indirectly messes with COM reference counting? 
 
Since the move from MFC 6.x, we have not been worried about backwards build compatibility. I will make sure to delete the directories with unsupported build files.
 
If you don't mind sending me the patches (or preferably the whole source files) to all of your fixes and I can take care of the rest. 
 
Thanks!
Ved 



On Monday, January 13, 2014 12:45 PM, Robert Randall <rob...@gm...> wrote:
  
I also fixed a problem when running in batch mode.  The destruction sequence of Windows causes an exception.  The cheap fix is implementing a function in CGalileoApp.
>
>
>Regards,
>Robert
>
>
>
>
>On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall <rob...@gm...> wrote:
>
>
>>
>>Hello,
>>
>>I've spent some time fixing a few simple problems with the latest version of MFC using the current trunk.  The CFileDialog constructors were being called incorrectly causing reference counting problems with COM.   The COM classes should not have been initialized in the first place.  Because the code was messing with m_bVistaStyle directly (not a good idea) it was causing the COM classes to be created but not destroyed which results in exceptions when running in the debugger and leaks resource when running a release build.
>>
>>
>>I made these changes using VS 2012 and I don't have the tools to know if the CFileDialog constructor is compatible with previous releases of MFC.  I'm not sure how old a tool set is supported by the project when compiling on Windows.  Which versions of the compiler and MFC are supported? 
>>
>>
>>The constructor in the version of MFC I'm using is:
>>
>>
>>CFileDialog( BOOL bOpenFileDialog, LPCTSTR lpszDefExt = NULL, LPCTSTR lpszFileName = NULL, DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, LPCTSTR lpszFilter = NULL, CWnd* pParentWnd = NULL, DWORD dwSize = 0, BOOL bVistaStyle = TRUE
);
>>
>>
>>I found one other minor problem.  When using a file on disk for testing the minimum Maximum Disk Size in sectors MUST be 128 or larger because of the code that IOTargetDisk::Prepare assumes that at least 64Kb will be written to the file.  A smaller value results in a divide by zero exception.  I'm not sure if Prepare should be fixed to handle smaller files or a minimum size should be enforced by the GUI.  Happy to make the fix either way.
>>
>>
>>
>>
>>
>>Let me know if you would like a patch for these changes.
>>
>>
>>Best regards,
>>Robert
>>
>>
-- 
>>Robert Randall | rob...@gm...  
>
>
>
>-- 
>Robert Randall | rob...@gm... 
>
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today. 
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>_______________________________________________
>Iometer-devel mailing list
>Iom...@li...
>https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>     

Re: [Iometer-devel] a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

I also fixed a problem when running in batch mode.  The destruction
sequence of Windows causes an exception.  The cheap fix is implementing a
function in CGalileoApp.

Regards,
Robert


On Mon, Jan 13, 2014 at 2:17 PM, Robert Randall
<rob...@gm...>wrote:

>
> Hello,
>
> I've spent some time fixing a few simple problems with the latest version
> of MFC using the current trunk.  The CFileDialog constructors were being
> called incorrectly causing reference counting problems with COM.   The COM
> classes should not have been initialized in the first place.  Because the
> code was messing with m_bVistaStyle directly (not a good idea) it was
> causing the COM classes to be created but not destroyed which results in
> exceptions when running in the debugger and leaks resource when running a
> release build.
>
> I made these changes using VS 2012 and I don't have the tools to know if
> the CFileDialog constructor is compatible with previous releases of MFC.
>  I'm not sure how old a tool set is supported by the project when compiling
> on Windows.  Which versions of the compiler and MFC are supported?
>
> The constructor in the version of MFC I'm using is:
>
> CFileDialog(
>    BOOL bOpenFileDialog,
>    LPCTSTR lpszDefExt = NULL,
>    LPCTSTR lpszFileName = NULL,
>    DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
>    LPCTSTR lpszFilter = NULL,
>    CWnd* pParentWnd = NULL,
>    DWORD dwSize = 0,
>    BOOL bVistaStyle = TRUE
> );
>
>
> I found one other minor problem.  When using a file on disk for testing
> the minimum Maximum Disk Size in sectors MUST be 128 or larger because of
> the code that IOTargetDisk::Prepare assumes that at least 64Kb will be
> written to the file.  A smaller value results in a divide by zero
> exception.  I'm not sure if Prepare should be fixed to handle smaller files
> or a minimum size should be enforced by the GUI.  Happy to make the fix
> either way.
>
>
> Let me know if you would like a patch for these changes.
>
> Best regards,
> Robert
>
> --
> Robert Randall | rob...@gm...
>



-- 
Robert Randall | rob...@gm...

[Iometer-devel] a couple fixes, are the maintainers interested?

[Robert R. <rob...@gm...>]

Hello,

I've spent some time fixing a few simple problems with the latest version
of MFC using the current trunk.  The CFileDialog constructors were being
called incorrectly causing reference counting problems with COM.   The COM
classes should not have been initialized in the first place.  Because the
code was messing with m_bVistaStyle directly (not a good idea) it was
causing the COM classes to be created but not destroyed which results in
exceptions when running in the debugger and leaks resource when running a
release build.

I made these changes using VS 2012 and I don't have the tools to know if
the CFileDialog constructor is compatible with previous releases of MFC.
 I'm not sure how old a tool set is supported by the project when compiling
on Windows.  Which versions of the compiler and MFC are supported?

The constructor in the version of MFC I'm using is:

CFileDialog(
   BOOL bOpenFileDialog,
   LPCTSTR lpszDefExt = NULL,
   LPCTSTR lpszFileName = NULL,
   DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
   LPCTSTR lpszFilter = NULL,
   CWnd* pParentWnd = NULL,
   DWORD dwSize = 0,
   BOOL bVistaStyle = TRUE
);


I found one other minor problem.  When using a file on disk for testing the
minimum Maximum Disk Size in sectors MUST be 128 or larger because of the
code that IOTargetDisk::Prepare assumes that at least 64Kb will be written
to the file.  A smaller value results in a divide by zero exception.  I'm
not sure if Prepare should be fixed to handle smaller files or a minimum
size should be enforced by the GUI.  Happy to make the fix either way.


Let me know if you would like a patch for these changes.

Best regards,
Robert

-- 
Robert Randall | rob...@gm...

[Iometer-devel] 1.1.0 Bug report - .ICF file open/read broken

[Howard M. <hm...@na...>]

Gents,



I’ve been a user of IOmeter for many years running tests for product
reviews at publications from PC Magazine to NetworkComputing where I’ve
been a contributing editor since 1998.  More recently I’ve been running a
storage analyst firm and independent test lab



Like most people I’ve been using the 2006 stable release. However as
storage systems have become more sophisticated the need for a version that
can use different data patterns has been more apparent so  I’ve been trying
to use 1.1.



In that effort I’ve discovered that the .ICF file save and open logic is
broken.  If you simply save the default configuration that is created on
IOmeter startup and then try to read the same file back you get a message
“error restoring file. Version number earlier than 1998.01.05 or
incorrectly formatted.”



The problem is clearly that the new 1.1.0 version saves the version as
1.1.0 but the .ICF file read module was never updated to deal with the
version number format change.  If I replace the version line in the .ICF
file with “Version 2006.07.27” from an older file it will read properly.



A bigger problem is that 1.1.0 cannot read .ICF files from 2006.07.27. I
have spent MANY hours developing custom access specifications and do need
to import them if 1.1.0 is to be useable at all. In the latest version on
sourceforge when I import an .ICF created with an older version all the
workers disappear from the GUI



Howard Marks

Chief Scientist

DeepStorage, LLC

Re: [Iometer-devel] Enhancements in IOmeter

[Allen, W. <way...@in...>]

Hi Martin,

I'm one of the active admins for the IOMeter project. I can assure you we haven't abandoned the project. As Joe mentioned, since IOMeter is a second (or third, fourth, etc.) job for those of us working on it, our availability to do active work on it varies. We do have a bin list of features users have asked for. We typically don't have time to implement these ourselves; however if code is contributed from folks like yourself, we are happy to review and get it on the mainline. As Joe also kindly pointed out, you can achieve the workload you mentioned by mixing access specifications. Let me know if you need assistance in setting that up.

Cheers,

Wayne

From: Martin Werner // adagio [mailto:mar...@ad...]
Sent: Saturday, August 24, 2013 7:27 AM
To: iom...@li...
Subject: [Iometer-devel] Enhancements in IOmeter

Hi,

as none of the project admin in IOmeter is reacting to messages via sourceforge I'd like to ask if this project has been abandoned meanwhile? As I'd like to add some functionality (and already have in my own development branches) I'd like to make them available to the public and as IOmeter official releases...

The primary area of enhancement I'd implement is the possibility to provide locality (or I/O skew) to allow to apply more representative random patterns (i.e. 80% of the I/O's to 20% of the capacity and the like) - I'm sure that there is a lot more of interest for others so I'd have a look into the requests for enhancements and see what could be fulfilled too.

What's your opinion about enhancements that you'd like to see?

Cheers, Martin

Re: [Iometer-devel] Enhancements in IOmeter

[<jo...@ei...>]

That functionality is already achievable(or at least it was a decade  
ago when I was doing a lot with IOmeter) by using multiple workers and  
setting appropriate offsets and sizes. I would commonly setup runs to  
imitate something like metadata log access to one area while doing  
streaming access to the rest(my previous life involved lots of  
realtime video editing use cases)

Open source projects are tough because interest and time resources  
shift over time but I'm sure the current maintainers would welcome  
some patches for improvements....or even if they don't make them in to  
the mainline you could certainly post them for others to consume.

Good luck with your testing,
Joe


Quoting Martin Werner // adagio <mar...@ad...>:

> Hi,
>
> as none of the project admin in IOmeter is reacting to messages via  
> sourceforge I'd like to ask if this project has been abandoned  
> meanwhile? As I'd like to add some functionality (and already have  
> in my own development branches) I'd like to make them available to  
> the public and as IOmeter official releases...
>
> The primary area of enhancement I'd implement is the possibility to  
> provide locality (or I/O skew) to allow to apply more representative  
> random patterns (i.e. 80% of the I/O's to 20% of the capacity and  
> the like) - I'm sure that there is a lot more of interest for others  
> so I'd have a look into the requests for enhancements and see what  
> could be fulfilled too.
>
> What's your opinion about enhancements that you'd like to see?
>
> Cheers, Martin
>

[Iometer-devel] Enhancements in IOmeter

[Martin W. // a. <mar...@ad...>]

Hi,

as none of the project admin in IOmeter is reacting to messages via sourceforge I'd like to ask if this project has been abandoned meanwhile? As I'd like to add some functionality (and already have in my own development branches) I'd like to make them available to the public and as IOmeter official releases...

The primary area of enhancement I'd implement is the possibility to provide locality (or I/O skew) to allow to apply more representative random patterns (i.e. 80% of the I/O's to 20% of the capacity and the like) - I'm sure that there is a lot more of interest for others so I'd have a look into the requests for enhancements and see what could be fulfilled too.

What's your opinion about enhancements that you'd like to see?

Cheers, Martin

Re: [Iometer-devel] Hostname error with Dynamo r141 on CentOS 6.4

[Gruher, J. R <jos...@in...>]

Ah, I figured out if I manually add an entry to /etc/hosts it will work around this problem.  Never mind. :)  Thanks anyway!

From: Gruher, Joseph R
Sent: Thursday, August 01, 2013 12:46 PM
To: 'iom...@li...'; 'iom...@li...'
Cc: Gruher, Joseph R
Subject: Hostname error with Dynamo r141 on CentOS 6.4

Hello-

I downloaded r141 and built on CentOS 6.4.  However, I get a hostname error when I try to run, even when specifying the "-m" switch.  Error shown below.  I can ping the Iometer machine so I know my system is on the network.  Anyone have any thoughts what could be the problem?  Thanks!

[root@node06 ~]# ./dynamo -m 12.12.12.106 -i 12.12.12.142
Dynamo version 1.1.0, x86-64, build Aug  1 2013 12:23:33

===> ERROR: Getting host name for "node06.joeboot.org" failed.
     [PortTCP::Create() in IOPortTCP.cpp line 238]
     errno = 11
*** Could not create a TCP/IP Port. exiting...

Re: [Iometer-devel] [Iometer-user] Hostname error with Dynamo r141 on CentOS 6.4

[<Wes...@De...>]

Hey Justin (and anyone else interested in unsubscribing),

Go to this link and select "Subscribe" for the list you want to unsubscribe from. (devel or user).

http://www.iometer.org/doc/mailinglists.html

Scroll to the bottom of the page where you see this:

"To unsubscribe from Iometer-devel, get a password reminder, or change your subscription options enter your subscription email address:"

Fill in your e-mail and follow the instructions.

Thanks!

Wes Vaske
Systems Engineer
Dell | Oracle Solutions

From: Riggs, justin [mailto:jus...@nb...]
Sent: Thursday, August 01, 2013 2:49 PM
To: iom...@li...
Cc: iom...@li...
Subject: Re: [Iometer-user] Hostname error with Dynamo r141 on CentOS 6.4

UNSUBSCRIBE

On Thu, Aug 1, 2013 at 1:45 PM, Gruher, Joseph R <jos...@in...<mailto:jos...@in...>> wrote:
Hello-

I downloaded r141 and built on CentOS 6.4.  However, I get a hostname error when I try to run, even when specifying the "-m" switch.  Error shown below.  I can ping the Iometer machine so I know my system is on the network.  Anyone have any thoughts what could be the problem?  Thanks!

[root@node06 ~]# ./dynamo -m 12.12.12.106 -i 12.12.12.142
Dynamo version 1.1.0, x86-64, build Aug  1 2013 12:23:33

===> ERROR: Getting host name for "node06.joeboot.org<http://node06.joeboot.org>" failed.
     [PortTCP::Create() in IOPortTCP.cpp line 238]
     errno = 11
*** Could not create a TCP/IP Port. exiting...

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Iometer-user mailing list
Iom...@li...<mailto:Iom...@li...>
https://lists.sourceforge.net/lists/listinfo/iometer-user



--
Justin W. Riggs
Windows System Administrator
(Contractor - Valdez International)

Information Technology Directorate
Interior Business Center
303-969-6623 (Office)
jus...@nb...<mailto:bra...@nb...>
US Department of the Interior
Office of the Secretary
www.ibc.doi.gov<http://www.ibc.doi.gov/>

Your Focus: Your Mission
Our Focus: You

[Iometer-devel] Hostname error with Dynamo r141 on CentOS 6.4

[Gruher, J. R <jos...@in...>]

Hello-

I downloaded r141 and built on CentOS 6.4.  However, I get a hostname error when I try to run, even when specifying the "-m" switch.  Error shown below.  I can ping the Iometer machine so I know my system is on the network.  Anyone have any thoughts what could be the problem?  Thanks!

[root@node06 ~]# ./dynamo -m 12.12.12.106 -i 12.12.12.142
Dynamo version 1.1.0, x86-64, build Aug  1 2013 12:23:33

===> ERROR: Getting host name for "node06.joeboot.org" failed.
     [PortTCP::Create() in IOPortTCP.cpp line 238]
     errno = 11
*** Could not create a TCP/IP Port. exiting...

Re: [Iometer-devel] Linux bugs in iometer trunk

[Chris H. <cho...@gm...>]

I have some code changes in my sandbox.  When I have time, I try to get
them in shape for general consumption.

-Chris


On Sat, May 25, 2013 at 5:33 PM, Vedran Degoricija <ve...@ya...>wrote:

> Thanks Chris. We will look into this. A proposed code change could be
> helpful as well. ;)
>
> Regards,
> Ved
>
>    *From:* Chris Horneck <cho...@gm...>
> *To:* iometer-devel <iom...@li...>; iometer-user <
> iom...@li...>
> *Sent:* Wednesday, May 22, 2013 3:28 PM
> *Subject:* [Iometer-devel] Linux bugs in iometer trunk
>
> Greetings,
>
> I would like to point out a few bugs for Linux that I have encountered in
> the iometer trunk and describe their impact for others who may be
> encountering them.
>
> 1) For Linux IO using libaio, the return value of completed IOs, as
> returned by io_getevents, is not checked.  If an IO fails due to the user
> buffer not being properly aligned for O_DIRECT IO or for some other reason,
> the IO will still appear to succeed, even though it actually failed. In
> fact, if all your IOs fail, it will appear that you are getting amazing
> performance because the IOs will complete (with an unchecked error) very
> quickly.  This leads me to my next item...
>
> 2) For Linux IO, the "Full Random" pattern generates IO with buffers that
> are not properly aligned for O_DIRECT IO.  Hence, all your IOs fail, but
> due to #1, it will appear that you are getting amazing performance.
>  IOGrunt aligns the buffer to a DWORD boundary, but this is not sufficient.
>  It should be sufficient to align the buffer to 512 byte boundary instead.
>
> 3) The IO Grunt destructor frees "write_data".  If you have used "Full
> Random", write_data may point to some random offset within the actual
> buffer that was allocated.  Attempting to free this pointer may have
> undefined results, including a crash.
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring
> service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Iometer-devel mailing list
> Iom...@li...
> https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>

Re: [Iometer-devel] Linux bugs in iometer trunk

[Vedran D. <ve...@ya...>]

Thanks Chris. We will look into this. A proposed code change could be helpful as well. ;)
 
Regards,
Ved


>________________________________
> From: Chris Horneck <cho...@gm...>
>To: iometer-devel <iom...@li...>; iometer-user <iom...@li...> 
>Sent: Wednesday, May 22, 2013 3:28 PM
>Subject: [Iometer-devel] Linux bugs in iometer trunk
>  
>
>
>Greetings,
>
>
>I would like to point out a few bugs for Linux that I have encountered in the iometer trunk and describe their impact for others who may be encountering them.
>
>
>1) For Linux IO using libaio, the return value of completed IOs, as returned by io_getevents, is not checked.  If an IO fails due to the user buffer not being properly aligned for O_DIRECT IO or for some other reason, the IO will still appear to succeed, even though it actually failed. In fact, if all your IOs fail, it will appear that you are getting amazing performance because the IOs will complete (with an unchecked error) very quickly.  This leads me to my next item... 
>
>
>2) For Linux IO, the "Full Random" pattern generates IO with buffers that are not properly aligned for O_DIRECT IO.  Hence, all your IOs fail, but due to #1, it will appear that you are getting amazing performance.  IOGrunt aligns the buffer to a DWORD boundary, but this is not sufficient.  It should be sufficient to align the buffer to 512 byte boundary instead.   
>
>
>3) The IO Grunt destructor frees "write_data".  If you have used "Full Random", write_data may point to some random offset within the actual buffer that was allocated.  Attempting to free this pointer may have undefined results, including a crash. 
>
>
>Regards,
>Chris
>------------------------------------------------------------------------------
>Try New Relic Now & We'll Send You this Cool Shirt
>New Relic is the only SaaS-based application performance monitoring service 
>that delivers powerful full stack analytics. Optimize and monitor your
>browser, app, & servers with just a few lines of code. Try New Relic
>and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>_______________________________________________
>Iometer-devel mailing list
>Iom...@li...
>https://lists.sourceforge.net/lists/listinfo/iometer-devel
>
>
>    

[Iometer-devel] Linux bugs in iometer trunk

[Chris H. <cho...@gm...>]

Greetings,

I would like to point out a few bugs for Linux that I have encountered in
the iometer trunk and describe their impact for others who may be
encountering them.

1) For Linux IO using libaio, the return value of completed IOs, as
returned by io_getevents, is not checked.  If an IO fails due to the user
buffer not being properly aligned for O_DIRECT IO or for some other reason,
the IO will still appear to succeed, even though it actually failed. In
fact, if all your IOs fail, it will appear that you are getting amazing
performance because the IOs will complete (with an unchecked error) very
quickly.  This leads me to my next item...

2) For Linux IO, the "Full Random" pattern generates IO with buffers that
are not properly aligned for O_DIRECT IO.  Hence, all your IOs fail, but
due to #1, it will appear that you are getting amazing performance.
 IOGrunt aligns the buffer to a DWORD boundary, but this is not sufficient.
 It should be sufficient to align the buffer to 512 byte boundary instead.

3) The IO Grunt destructor frees "write_data".  If you have used "Full
Random", write_data may point to some random offset within the actual
buffer that was allocated.  Attempting to free this pointer may have
undefined results, including a crash.

Regards,
Chris

[Iometer-devel] [ iometer-Bugs-3577291 ] Iometer Large Disk Support

[SourceForge.net <no...@so...>]

Bugs item #3577291, was opened at 2012-10-15 03:43
Message generated for change (Tracker Item Submitted) made by gmxyr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3577291&group_id=40179

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gavin Martin (gmxyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Iometer Large Disk Support

Initial Comment:
I have been trying to confirm that Iometer supports disks larger than 2.2TB, but it does not seem to be working.

I have written a pattern to specific LBA's above 2.2TB and when I put the LBA into the Disk Starting Sector field in the Iometer GUI and perform a sequential write I would expect the pattern to be overwritten, but this is not the case.  For LBA's below 2TB this works, but not above 2TB.  I have tried this with the 2008 version and the RC1.1 version, both 32bit and 64bit on a Windows 2003 64bit server installation, and neither seem to work above 2TB.

Does the Disk Starting Sector field accept LBA's larger than 2TB?


 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3577291&group_id=40179

[Iometer-devel] IOMeter - FreeBSD

[Suresh K. R. N <sur...@gm...>]

Hi,



I am planning to use IOMeter on FreeBSD,  my understanding is that the
IOMeter does not support the FreeBSD as of now. Could you please let me
know what are the changes required in the source code to make it compatible
or any plug-in is already available.



It would be really helpful if you could share any documentation on the
IOMeter on FreeBSD.



Thanks in advance,



N.Suresh

[Iometer-devel] [ iometer-Bugs-3564999 ] User Warning missing!!!

[SourceForge.net <no...@so...>]

Bugs item #3564999, was opened at 2012-09-05 05:54
Message generated for change (Tracker Item Submitted) made by kmalcher
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3564999&group_id=40179

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lsmod (kmalcher)
Assigned to: Nobody/Anonymous (nobody)
Summary: User Warning missing!!!

Initial Comment:
I buyed a SSD disk and wnat to do some performance tests now under Linux.
I tihought IOMeter is a benchmark program like others.
So i installed it and started it under Linux using the frontend with wine.
I choosed to use SDA and SDB as disks to compare.

The tool works perfect and after it ALL DATA WHERE DESTROYED ON THE DISKS!!!

There is no WARNING in the program or in the handbook that this PROGRAM DESTROYES DATA!

In fact it is more worse than every VIRUS, because it writes randomly over the disk!
You can imagine what problems i have now to restore all my data.
IOMETER also killed the PARTITION TABLES!

This is unbelievable for a opensource software.
I don't know any other software that destroyes data wirhout warning.

Please make user warnings everywhere.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=427254&aid=3564999&group_id=40179