VC++ 2012: How to include version info from version.inc (maintained separately) into the .rc file - visual-c++-2012

Summary: Having the version details defined in the separately maintained version.inc via preprocessor macros... How to include the macro values into the resource version definition block?
My version.inc file is stored in UTF-8 (i.e. pure ASCII in the case). Its full content is the following (the APS_ prefix here is related to the real name of the application, not to the .aps file generated by the resource compiler):
#define APS_MAJORNUMBER 4
#define APS_MINORNUMBER 5
#define APS_BUILDNUMBER 0
#define APS_MODIFICATIONNUMBER 0
#define APS_BUILDEXT "wx"
#define APS_DATEYEAR 2012
#define APS_DATEMONTH 10
#define APS_DATEDAY 4
The Visual Studio 2012 C++ seems to be more picky about the resource script file (app.rc) than the Visual Studio 2010 was. The first thing I have noticed is that when editing it manually, I have to keep the UTF-16 encoding. Can you confirm that? Is there any documentation on that?
Say the version block in the app.rc looks like this:
/////////////////////////////////////////////////////////////////////////////
//
// Version
//
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,0,0,1
PRODUCTVERSION 1,0,0,1
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x1L
#else
FILEFLAGS 0x0L
#endif
FILEOS 0x40004L
FILETYPE 0x1L
FILESUBTYPE 0x0L
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040504b0"
BEGIN
VALUE "CompanyName", "TODO: <Company name>"
VALUE "FileDescription", "TODO: <File description>"
VALUE "FileVersion", "1.0.0.1"
VALUE "InternalName", "app.exe"
VALUE "LegalCopyright", "Copyright (C) 2012"
VALUE "OriginalFilename", "app.exe"
VALUE "ProductName", "TODO: <Product name>"
VALUE "ProductVersion", "1.0.0.1"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x405, 1200
END
END
In the earlier versions of Visual Studio (2005 and 2010), I was able to have the related version.rc2 like this:
/////////////////////////////////////////////////////////////////////////////
//
// Version
//
#include "version.inc"
#define STR(value) #value
#define STRINGIZE(value) STR(value)
#define APS_FULLVERSION_STR \
STRINGIZE(APS_MAJORNUMBER) "." \
STRINGIZE(APS_MINORNUMBER) "." \
STRINGIZE(APS_BUILDNUMBER) "." \
STRINGIZE(APS_MODIFICATIONNUMBER)
VS_VERSION_INFO VERSIONINFO
FILEVERSION APS_MAJORNUMBER,APS_MINORNUMBER,APS_BUILDNUMBER,APS_MODIFICATIONNUMBER
PRODUCTVERSION APS_MAJORNUMBER,APS_MINORNUMBER,APS_BUILDNUMBER,APS_MODIFICATIONNUMBER
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x29L
#else
FILEFLAGS 0x28L
#endif
FILEOS 0x4L
FILETYPE 0x1L
FILESUBTYPE 0x0L
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "000004b0"
BEGIN
VALUE "Comments", "A fairly useful tool named APS"
VALUE "CompanyName", "The company name"
VALUE "FileDescription", "app"
VALUE "FileVersion", APS_FULLVERSION_STR
VALUE "InternalName", "aps"
VALUE "LegalCopyright", "Copyright © 1993-" STRINGIZE(APS_DATEYEAR)
VALUE "OriginalFilename", "app.exe"
VALUE "PrivateBuild", ""
VALUE "ProductName", "APS of the version 4"
VALUE "ProductVersion", APS_FULLVERSION_STR
VALUE "SpecialBuild", APS_BUILDEXT
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x0, 1200
END
END
Then the version.rc2 was included into the app.rc via editing the app.rc manually. However, I cannot repeat the process with the Visual Studio 2012 project and resource file. I may be doing some mistake invisible to me. Should that approach work also in Visual Studio 2012?
Thanks for you time and experience,
Petr

Here is the way to do it via Visual Studio 2012 (C++, IDE). Firstly, it seems that all the files (app.rc, version.rc2 with the version section to be included into app.rc, and also the version.inc with the values maintained separately [included into version.rc2]) must be stored in UTF-16 -- unlike in the earlier versions of Visual Studio. Then I was able to repeat the same approach also in Visual Studio 2012.
However, you do not need to edit the app.rc file manually. You can use the following steps using the IDE:
Open the project (App) and switch to the Resource View tab.
Unfold the App project, unfold its app.rc, and unfold the Version folder. You can see the VS_VERSION_INFO item.
Mark the VS_VERSION_INFO item and pres Delete key on the keyboard. The item and its upper Version folder disappear.
Mouse right-click the app.rc folder, and select the Resource Includes.... The dialog with the same name and with three input panes appear.
Focus on the bottom pane named Compile-time directives:, and write the #include "version.rc2" there. (The file must not have the .rc extension, but the .rc2 is fine and recommended elsewhere in the MSDN doc.)
Press OK, and save all files (to save also the modified app.rc).
The result of the steps is that you will not see the Version folder and the VS_VERSION_INFO item in the resource tree (see Resource View tab); however, the above mentioned constructed Version section (stored inside the version.rc2) is compiled into the application resources.
Technically, the following parts of the app.rc file can be found after the steps:
3 TEXTINCLUDE
BEGIN
"#include ""version.rc2""\r\n"
"\0"
END
...
#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//
#include "version.rc2"
/////////////////////////////////////////////////////////////////////////////
#endif // not APSTUDIO_INVOKED
Any constructive comments to enhance the topic are welcome and will be +1-ed :)
Have a nice time,
Petr

Related

How to call DLL exported functions with #<number> at end of function name from C

I am trying to call functions from ntvdm.lib in Visual Studio 2019 using the Visual Studio 2017 - Windows XP (v141_XP) platform toolset, with the following defined:
#define _WIN32_WINNT 0x0501
#define i386
running dumpbin /exports on the LIB file I get the following output:
Microsoft (R) COFF/PE Dumper Version 14.29.30037.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ntvdm.lib
File Type: LIBRARY
Exports
ordinal name
_BlockWOWIdle#4
_CurrentMonitorTeb
_DBGNotifyDebugged#4
_DBGNotifyNewTask#8
_DBGNotifyRemoteThreadAddress#8
_DispatchInterrupts#0
_Dos_Flag_Addr
_DpmiSetIncrementalAlloc#4
_ExpLdt
_FlatAddress
_GetDOSAppName#4
_InitialVdmDbgFlags
_InitialVdmTibFlags
_IsCdRomFile#4
_MGetVdmPointer#12
_RedirectLongFileName#12
_RedirectShortFileName#12
_RegisterWOWIdle#0
_ResumeTimerThread#0
_SelectorLimit
_SetShadowDescriptorEntries#8
_ShortPathEnvVar#4
_Sim32pGetVDMPointer#8
_SoftPcEoi#8
_SuspendTimerThread#0
_VDDAllocMem#12
_VDDAllocateDosHandle#12
_VDDAssociateNtHandle#12
_VDDDeInstallIOHook#12
_VDDDeInstallMemoryHook#12
_VDDDeInstallUserHook#4
_VDDExcludeMem#12
_VDDFreeMem#12
_VDDIncludeMem#12
_VDDInstallIOHook#16
_VDDInstallMemoryHook#16
_VDDInstallUserHook#20
_VDDQueryDMA#12
_VDDReleaseDosHandle#8
_VDDReleaseIrqLine#8
_VDDRequestDMA#16
_VDDReserveIrqLine#8
_VDDRetrieveNtHandle#16
_VDDSetDMA#16
_VDDSimulate16#0
_VDDTerminateVDM#0
_VdmDbgAttach#0
_VdmGetParametersInfoError#0
_VdmMapFlat#12
_VdmParametersInfo#12
_VdmTraceEvent#12
_WOWSysErrorBox#20
_WaitIfIdle#0
_call_ica_hw_interrupt#12
_cmdCheckTemp#4
_cmdCheckTempInit#0
_cpu_createthread#8
_demClientErrorEx#12
_demFileDelete#4
_demFileFindFirst#12
_demFileFindNext#4
_demGetFileTimeByHandle_WOW#4
_demGetPhysicalDriveType#4
_demIsShortPathName#8
_demLFNCleanup#0
_demLFNGetCurrentDirectory#8
_demSetCurrentDirectoryGetDrive#8
_demWOWLFNAllocateSearchHandle#4
_demWOWLFNCloseSearchHandle#4
_demWOWLFNEntry#4
_demWOWLFNGetSearchHandle#4
_demWOWLFNInit#4
_fSeparateWow
_getAF#0
_getAH#0
_getAL#0
_getAX#0
_getBH#0
_getBL#0
_getBP#0
_getBX#0
_getCF#0
_getCH#0
_getCL#0
_getCS#0
_getCX#0
_getDF#0
_getDH#0
_getDI#0
_getDL#0
_getDS#0
_getDX#0
_getEAX#0
_getEBP#0
_getEBX#0
_getECX#0
_getEDI#0
_getEDX#0
_getEFLAGS#0
_getEIP#0
_getES#0
_getESI#0
_getESP#0
_getFS#0
_getGS#0
_getIF#0
_getIP#0
_getIntelRegistersPointer#0
_getMSW#0
_getOF#0
_getPF#0
_getSF#0
_getSI#0
_getSP#0
_getSS#0
_getZF#0
_host_CreateThread#24
_host_ExitThread#4
_host_com_close#4
_host_direct_access_error#4
_host_simulate#0
_pDeviceChain
_setAF#4
_setAH#4
_setAL#4
_setAX#4
_setBH#4
_setBL#4
_setBP#4
_setBX#4
_setCF#4
_setCH#4
_setCL#4
_setCS#4
_setCX#4
_setDF#4
_setDH#4
_setDI#4
_setDL#4
_setDS#4
_setDX#4
_setEAX#4
_setEBP#4
_setEBX#4
_setECX#4
_setEDI#4
_setEDX#4
_setEFLAGS#4
_setEIP#4
_setES#4
_setESI#4
_setESP#4
_setFS#4
_setGS#4
_setIF#4
_setIP#4
_setMSW#4
_setOF#4
_setPF#4
_setSF#4
_setSI#4
_setSP#4
_setSS#4
_setZF#4
Summary
BD .debug$S
14 .idata$2
14 .idata$3
4 .idata$4
4 .idata$5
A .idata$6
The function definition I'm trying to call in VDDSVC.h is:
#define GetVDMPointer(Address, Size, Mode) Sim32GetVDMPointer(\
Address, Size, Mode)
However visual studio error is:
Error LNK2019 unresolved external symbol _MGetVdmPointer referenced in function _VddDispatch
_MGetVdmPointer is in the lib file but referenced as _MGetVdmPointer#12
I reviewed the options here but couldn't determine which one might apply in my scenario https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2019?view=msvc-170
In Linker -> General -> Show Progress I tried setting /VERBOSE although no additional information was generated in the logs
I tried changing calling convention to "__stdcall" in C/C++ -> Advanced Calling Convention
I've tried changing files from .C to .CPP although get similar error (Although the symbol looked for is a c++ mangled style name)
The issue was calling convention needs to be modified to "__stdcall" in C/C++ -> Advanced Calling Convention
Which I had tried, however Visual Studio 2019 project properties was defaulting to configuration for "Release" build and not the current build type "Debug(Active)" which effectively made my initial change of that setting ineffective.
As suggested in comments by IInspectable:
When changing global project properties, always make sure the "Configuration" is set to "All Configurations" and "Platform" is set to "All Platforms"

Precompile embedded sql in c on ubuntu linux db2 does not work

I asked before but it looks like its not me, its the system..
My db2 installation completed with "minor errors" so maybe that is it.
I can't make out the error code explanations.
The content of the folder:
prog1.sqc sh.sh
I gave DBADM authority to instance user.
It should create bnd file on its own, correct?
Here is the report:
$ db2 precompile prog1.sqc bindfile
LINE MESSAGES FOR prog1.sqc
------ --------------------------------------------------------------------
SQL0060W The "C" precompiler is in progress.
SQL0031C File "/home/nikica/UCENJE/precompile/prog1.bnd"
could not be opened.
SQL0095N No bind file was created because of previous
errors.
SQL0091W Precompilation or binding was ended with "2"
errors and "0" warnings.
IBM support pages:
https://www.ibm.com/support/pages/running-db2look-db2-instance-user-fails-sql0031c-file-db2lkfunbnd-could-not-be-opened
EDIT: my sqc
#include <stdio.h>
#include <string.h>
#include <sqlca.h>
/* SQL includes */
EXEC SQL INCLUDE SQLCA;
EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL END DECLARE SECTION;
int main()
{
// EXEC SQL CONNECT TO sample;
return (0);
}
RESOLVED with
Precompilation or binding was ended with "0"
errors and "0" warnings.
Thanks to mao
Did all the steps like 100 times before plus "su - root" in the beginning

sprintf_s(and sprintf also) has error in Windows 7 64 bits with Visual Studio 2013

I am programming in Windows 7 64 bits with VS 2013.
I already have a code which was developed in Linux 64 bits. That code is full of sprintf() functions.
Now, I run that code in Windows 64 bits, it shows alert windows.
At first, I tried sprintf, and it shows use sprintf_s. So I changed.
After change my code window shows this error.
Program : ...visual studio
2012\Project\IIS_Partial\Debug\IIS_Partial.exe
File : f\dd\vctools\crt_bld\self_x86\crt\src\vsprintf.c
Line : 233
Expression : format != NULL
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press retry to debug the application)
Actually my code is made in C. Why this refers C++.
And I could even debug, because pressing the "debug" button directly goes to this error window. Are there any clues?
Thanks for reading:D
It was just a simple configuration matter.
Basically Microsoft Visual Studio 2012 is compiling as 32 bits.
So if someone want to run a source code in 64 bits, has to change options.
right click on [solution] -> [properties] -> [Configuration] -> [Configuration Manager](right upper corner of window) -> [Active Solution Platform] flow Menu -> -> upper is 'x64' and lower is 'Win32'. check the lower box.
and confirm. Now it builds in 64 bits environment.
Original Explanation from Microsoft Official site is :
http://msdn.microsoft.com/en-us/library/vstudio/9yb4317s.aspx

Editing php.ini to instal Xdebug

All,
I'm a relative newbie programmer and I want to install Xdebug to help me debug my PHP work. I'm using Wamp on a Windows XP machine.
I uploaded the content of my phpinfo() onto the Xdebug site, and as part of the tailored installation instructions I get:
Edit C:\wamp\bin\apache\Apache2.2.11\bin\php.ini and add the line
zend_extension =
c:\wamp\bin\php\php5.3.0\ext\php_xdebug-2.1.2-5.3-vc6.dll
I have never opened that file before, and when I open it I find that every single setting is placed in a paragraph with some comments - for example:
[Tidy]
; The path to a default tidy configuration file to use when using tidy
; http://php.net/tidy.default-config
;tidy.default_config = /usr/local/lib/php/default.tcfg
; Should tidy clean and repair output automatically?
; WARNING: Do not use this option if you are generating non-html content
; such as dynamic images
; http://php.net/tidy.clean-output
tidy.clean_output = Off
So should I type something like that:
[Xdebug]
; This is the line to be inserted per the set-up instructions (2012-01-05)
zend_extension = c:\wamp\bin\php\php5.3.0\ext\php_xdebug-2.1.2-5.3-vc6.dll
I assume the [...] and the ; are not read by the server but I'm really not sure what they are and I don't want to screw things up...
Thanks,
JDelage
you only need the one line. Sections [..] and ; are ignored in PHP's parser. So all you need is:
zend_extension = c:\wamp\bin\php\php5.3.0\ext\php_xdebug-2.1.2-5.3-vc6.dll
cheers.
Derick

Why is GNU patch failing for this diff?

G'day,
Edit: Just thought I'd mention that this somewhat long question is now fixed thanks to Adam Goode's answer below if you're just skimming while passing through.
I've been given a patch to add to Apache 2.2.14 and one unified diff is not patching the file at all. I'm using GNU patch 2.5.4.
I have to ignore whitespace because the original patch wasn't made well, i.e. many of the diffs are seemingly for tab -> spaces conversions. These sorts of diffs are even less useful because the patch file has been modified somewhere along the delivery chain, e.g. svn repository, Jira system, web interface, etc., so that all tabs have been converted to spaces anyway!
The command I am using on Solaris 10 is:
/usr/bin/gpatch --verbose --ignore-whitespace -p1 -d . \
<mod_cache.diff
and the output is:
...
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: httpd/modules/cache/mod_cache.h
|===================================================================
|--- httpd/modules/cache/mod_cache.h
|+++ httpd/modules/cache/mod_cache.h
--------------------------
Patching file modules/cache/mod_cache.h using Plan A...
Hunk #1 succeeded at 24.
Hunk #2 succeeded at 86.
Hunk #3 succeeded at 138.
Hunk #4 succeeded at 163.
Hunk #5 succeeded at 184.
Hunk #6 succeeded at 217.
Hunk #7 succeeded at 271.
Hunk #8 succeeded at 380.
...
Notice the
Hunk #2 succeeded at 86.
line.
The patch file contains several unified diffs but the relevant diff is:
...
Index: httpd/modules/cache/mod_cache.h
===================================================================
--- httpd/modules/cache/mod_cache.h
+++ httpd/modules/cache/mod_cache.h
## -86,9 +86,13 ##
#define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
#define DEFAULT_CACHE_EXPIRE MSEC_ONE_HR
#define DEFAULT_CACHE_LMFACTOR (0.1)
+#define DEFAULT_CACHE_MAXAGE 5
+#define DEFAULT_CACHE_LOCKPATH "/mod_cache-lock"
+#define CACHE_LOCKNAME_KEY "mod_cache-lockname"
+#define CACHE_LOCKFILE_KEY "mod_cache-lockfile"
-/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and
- * PROXY_DECLARE_DATA with appropriate export and import tags for the platform
+/* Create a set of CACHE_DECLARE(type), CACHE_DECLARE_NONSTD(type) and
+ * CACHE_DECLARE_DATA with appropriate export and import tags for the platform
*/
#if !defined(WIN32)
#define CACHE_DECLARE(type) type
...
and the relevant part of the source, after applying the patch (supposedly), with some added context, is:
...
#define MSEC_ONE_DAY ((apr_time_t)(86400*APR_USEC_PER_SEC)) /* one day, in microseconds */
#define MSEC_ONE_HR ((apr_time_t)(3600*APR_USEC_PER_SEC)) /* one hour, in microseconds */
#define MSEC_ONE_MIN ((apr_time_t)(60*APR_USEC_PER_SEC)) /* one minute, in microseconds */
#define MSEC_ONE_SEC ((apr_time_t)(APR_USEC_PER_SEC)) /* one second, in microseconds */
#define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
#define DEFAULT_CACHE_EXPIRE MSEC_ONE_HR
#define DEFAULT_CACHE_LMFACTOR (0.1)
/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and
* PROXY_DECLARE_DATA with appropriate export and import tags for the platform
*/
#if !defined(WIN32)
#define CACHE_DECLARE(type) type
#define CACHE_DECLARE_NONSTD(type) type
#define CACHE_DECLARE_DATA
#elif defined(CACHE_DECLARE_STATIC)
...
All other patches seem to have either been successfully applied or ignored.
Any ideas why this particular diff isn't taking?
Edit: After reducing the patch fuzz factor down to zero as recommended by Adam below, the patch has worked successfully.
Thanks to Adam Goode, if I could give you another vote up for the answer I would! Here's the relevant paragraph for fuzz in the GNU diffutils manual if you're interested.
Edit 2: BTW There's this highly relevant caveat at the bottom of that fuzz paragraph:
patch usually produces the correct results, even when it must make many guesses. However, the results are guaranteed only when the patch is applied to an exact copy of the file that the patch was generated from.
Unfortunately, in this case, I can't be sure that their mod_cache.h is the same as the official 2.2.14 mod_cache,h! )-:
When you use --ignore-whitespace and don't use --fuzz=0, you are basically telling patch that it should do a best-effort patch, instead of failing completely. Because it is best effort, there is really no way to assure that it will work perfectly. For this reason, git and Fedora RPM set --fuzz=0 by default so that these types of problems fail at patch time (instead of compile- or run-time).
If you want to preserve your files as upstream-tarball + patches, you should redo the patch and make sure it can apply with --fuzz=0.

Resources