EXE has the wrong date - Revision history

Jpdrolet at 22:38, 29 January 2009

2009-01-29T22:38:23Z

← Older revision		Revision as of 22:38, 29 January 2009
Line 1:		Line 1:
	Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe file consistently set to the same value and not to the current date and time? This occurs regardless of the settings of the system clock. It appears that this is a bug in the Windows operating system. As far as we are aware, Microsoft has been aware of it for at least three years but the bug does exist at least under Windows 95 and 98. It is unknown whether the newer versions of Windows (including NT) still exhibit this problem.		Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe file consistently set to the same value and not to the current date and time? This occurs regardless of the settings of the system clock. It appears that this is a bug in the Windows operating system. As far as we are aware, Microsoft has been aware of it for at least three years but the bug does exist at least under Windows 95 and 98. It is unknown whether the newer versions of Windows (including NT) still exhibit this problem.

	The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug. ~~A fix for this bug is available from:~~		The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug.

	~~[http://www.cybertechs.qc.ca/~jpdrolet/labview http://www.cybertechs.qc.ca/~jpdrolet/labview]~~		There are a couple of user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project.

	There are ~~also~~ a couple of ~~alternative~~ user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project.

	[http://sources.redhat.com/cygwin/ http://sources.redhat.com/cygwin/]		[http://sources.redhat.com/cygwin/ http://sources.redhat.com/cygwin/]

Michael_Aivaliotis at 09:08, 8 October 2007

2007-10-08T09:08:11Z

← Older revision		Revision as of 09:08, 8 October 2007
Line 10:		Line 10:

	Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process.		Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process.

			[[category:building executables]]

MichaelAivaliotis at 22:28, 17 March 2007

2007-03-17T22:28:23Z

← Older revision		Revision as of 22:28, 17 March 2007
Line 3:		Line 3:
	The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug. A fix for this bug is available from:		The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug. A fix for this bug is available from:

	[http://www.cybertechs.qc.ca/~jpdrolet/labview]		[http://www.cybertechs.qc.ca/~jpdrolet/labview http://www.cybertechs.qc.ca/~jpdrolet/labview]

	There are also a couple of alternative user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project.		There are also a couple of alternative user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project.

	[http://sources.redhat.com/cygwin/]		[http://sources.redhat.com/cygwin/ http://sources.redhat.com/cygwin/]

	Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process.		Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process.

MichaelAivaliotis: New page: Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe fi...

2007-03-17T22:28:04Z

New page: Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe fi...

New page

Under some operating systems a built application in LabVIEW versions 5 and 6 (specifically Windows based machines) has the last modified date reported by Windows for the application exe file consistently set to the same value and not to the current date and time? This occurs regardless of the settings of the system clock. It appears that this is a bug in the Windows operating system. As far as we are aware, Microsoft has been aware of it for at least three years but the bug does exist at least under Windows 95 and 98. It is unknown whether the newer versions of Windows (including NT) still exhibit this problem.

The problem occurs when the LabVIEW Appliction Builder copies the standalone stub from the APPLIBS directory (applib.llb) to the exe file and appends the VI code to it. The Windows functions used for this should modify the modified date of the file but leave it at the date of the original stub file. Although NI could theoretically add a manipulation to the Application Builder which really "touches" the file to update the modification date, this is only a workaround for someone elses bug. A fix for this bug is available from:

[http://www.cybertechs.qc.ca/~jpdrolet/labview]

There are also a couple of alternative user workarounds. If you are not parcelling up your application into distribution disks you can "touch" the built exe with the linux utility of the same name (free downloads of win32 based touch utilities are available on the net; e.g. from the CygWin project.

[http://sources.redhat.com/cygwin/]

Alternatively you could write a small application that reads one byte of the file and then writes that byte back to the file, thereby updating the modification time and date.You could also modify the applib.llb stub file directly just before building the application with either of the touch methods described above. This modification of the stub file will at least ensure that the files heading for the distribution disks end up with a file time and date close to that of the final build process.