I couldn't find the exact number of current Active Template Library (ATL) which distribute along with Visual Studio 2012. Does anyone have an idea about the exact version number ?
From atldef.h:
/////////////////////////////////////////////////////////////////////////////
// Master version numbers
#define _ATL 1 // Active Template Library
#define _ATL_VER 0x0A00 // Active Template Library version 10.00
#ifndef _ATL_FILENAME_VER
#define _ATL_FILENAME_VER "100"
#endif
#ifndef _ATL_FILENAME_VER_NUM
#define _ATL_FILENAME_VER_NUM 100
#endif
#ifndef _ATL_VER_RBLD
#define _ATL_VER_RBLD "10.00"
#endif
Related
I am trying to compile a .rc file to link the generated .res file to my linker to get my project resources to be included in my .exe.
The problem that I have is that I can't get RC to compile my .rc file.
I always get the same error message :
Blockquote fatal error RC1109: error creating stuff.res
And the verbose option doesn't help much and only adds this:
Blockquote Using codepage 1252 as default
I added my resources to my .rc using the resource editor dialog, I didn't write the file myself. The only thing that I did is to change the type "TXT" that I first though good to "RCDATA" in the above code :
// Microsoft Visual C++ generated resource script.
//
#include "resource1.h"
#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "winres.h"
/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
// Français (France) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_FRA)
LANGUAGE LANG_FRENCH, SUBLANG_FRENCH
#ifdef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// TEXTINCLUDE
//
1 TEXTINCLUDE
BEGIN
"resource1.h\0"
END
2 TEXTINCLUDE
BEGIN
"#include ""winres.h""\r\n"
"\0"
END
3 TEXTINCLUDE
BEGIN
"\r\n"
"\0"
END
#endif // APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// PNG
//
IDB_PNG1 PNG "Ressources\\Gamma-Sup.png"
IDB_PNG2 PNG "Ressources\\Interface.png"
/////////////////////////////////////////////////////////////////////////////
//
// Font
//
IDR_FONT1 FONT "Ressources\\font_1.ttf"
/////////////////////////////////////////////////////////////////////////////
//
// TXT
//
IDR_TXT1 RCDATA "Ressources\\Probe List.txt"
IDR_TXT2 RCDATA "Ressources\\ProgressBar - Green.txt"
IDR_TXT3 RCDATA "Ressources\\ProgressBar - Red.txt"
IDR_TXT4 RCDATA "Ressources\\ProgressBar - Yellow.txt"
#endif // Français (France) resources
/////////////////////////////////////////////////////////////////////////////
#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//
/////////////////////////////////////////////////////////////////////////////
#endif // not APSTUDIO_INVOKED
The IDS I am using are all defined in my .h file :
//{{NO_DEPENDENCIES}}
// fichier Include Microsoft Visual C++.
// Utilisé par GammaSup3.rc
//
#define IDB_PNG1 101
#define IDB_PNG2 102
#define IDR_FONT1 103
#define IDR_TXT1 104
#define IDR_TXT2 105
#define IDR_TXT3 106
#define IDR_TXT4 107
// Next default values for new objects
//
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE 108
#define _APS_NEXT_COMMAND_VALUE 40001
#define _APS_NEXT_CONTROL_VALUE 1001
#define _APS_NEXT_SYMED_VALUE 101
#endif
#endif
I used several commands to compile my file , all resulting in the same error message. As I start to have tried all the options available, I feel a bit lost.
Blockquote rc /d DEBUG /i c:/source/stuff/resources filename.rc
I tried without or with less options(/x /l). My project is in DEBUG configuration . I am sure that i don't have a typo in my path here cause i paste it from the file explorer.
I also tried to compile a just auto generated .rc file without adding any resources to it and RC still won't compile it.
What I want is Rc to generate a single language dependant .res file , not two.
I'm ashamed with the idea of asking you about some command line problem, but i'm pretty much a newbie and I really don't get what is going on here. Any suggestion is very welcome as I really would like to be able to use RC.
Why NTDDI_VERSION macro changes its value from cpp it includes to ntdddisk.h ?
I am using Visual Studio 2012 with cumulative update 4, and building on Windows 7 x64.
In one CPP i need to call new IOCTL_ .. for WIN 8.
In the CPP there is #include
ntdddisk.h defines the new IOCTL_ for WIN 8 under the guarded condition:
#if (NTDDI_VERSION >= NTDDI_WIN8)
...
#endif
Inside that cpp the NTDDI_VERSION macro has value NTDDI_WIN8 (as expected result from include sdkddkver.h and compilation with /D_WIN32_WINNT=0x0602)
However, in ntdddisk.h the value for NTDDI_VERSION macro has value < NTDDI_VISTA, that is, less than NTDDI_WIN8
Compilation fails with error
error C2065: 'IOCTL_..' : undeclared identifier
Looks like a bug unless i miss something else. Thoughts?
Details are:
In the CPP file there are these includes
#pragma once
// Needed for new IOCTL_ for WIN 8
#include <sdkddkver.h>
#include <windows.h>
// Check NTDDI_VERSION ...
#if (NTDDI_VERSION >= NTDDI_WIN8)
// Value is NTDDI_WIN8 as expected
// #include <TROUBLE.h>
#endif
#pragma pack(8)
#include <ntdddisk.h>
#include <ntddscsi.h>
#include <lm.h>
#include <objbase.h>
/*=== IMPORTANT: this struct needs to have 8-byte packing ===*/
typedef struct _SCSI_PASS_THROUGH_WITH_BUFFERS {
SCSI_PASS_THROUGH spt;
ULONG Filler; // realign buffers to double word boundary
UCHAR SenseBuf[32];
UCHAR DataBuf[512];
} SCSI_PASS_THROUGH_WITH_BUFFERS;
#pragma pack()
Compilation with CL has these parameters including with -D_WIN32_WINNT=0x0602
cl -nologo #COMPL.TMP /Fo..\\..\\..\\optimized\\obj\\x86\\CPP.obj CPP.cpp
COMPL.TMP contains
/I*** application-headers ***
-D_AFXDLL -c -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DBTREEDB -O2 -Ox -MD -Zi -DNT_CLIENT -DWIN32 -D"_CONSOLE" -D_THREADS -D_OPSYS_TYPE=DS_WINNT -DPSAPI_VERSION=1 -D_WIN32_WINNT=0x0602 -TP -DMBCS=1 -D_LONG_LONG=1 -D_DSM_VLK_BTREE -DDSM_WIDECHAR -D_UNICODE -DUNICODE -DUSE_XML=1 -DXMLUTIL_EXPORTS=1 -DUSE_XERCES_2_8=1 -DPEGASUS_PLATFORM_WIN32_IX86_MSVC=1 -DPEGASUS_USE_EXPERIMENTAL_INTERFACES -Zp1 -D_DSM_LONG_NAME -W3 -EHsc -GF
The problem isn't with the _WIN32_WINNT or NTDDI_VERSION macros.
The problem is that windows.h indirectly includes winioctl.h which has the following curious couple of lines about halfway through:
#ifndef _NTDDDISK_H_
#define _NTDDDISK_H_
Unsurprisingly, ntdddisk.h starts with those very same lines and therefore is effectively not included at all.
I couldn't easily come up with a combination or ordering of headers that would work around this problem - I think it's something that MS really needs to fix.
However, the following terrible workaround (that I really don't suggest, unless you can't get any help from MS) seemed to get the compiler to actually process ntdddisk.h:
#define _NTDDDISK_H_
#include <windows.h>
#undef _NTDDDISK_H_
But, I suspect there may be other problems that might pop up as a result of this hack - so if you decide to use it, please test carefully.
I am not sure that this is what i need, but the compilation worked after inserting
#define _NTDDDISK_H_
#include <windows.h>
...
#undef _NTDDDISK_H_
#include <ntdddisk.h>
Thanks for suggestion.
What's the difference between these two files? I can't really get it. I should mention that the first file should be arch/x86/include/asm/unistd_32.h (or and _64.h). Here is a quick preview of what they contain:
arch/x86/include/asm/unistd.h:
#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H
/*
* This file contains the system call numbers.
*/
#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
#define __NR_write 4
#define __NR_open 5
#define __NR_close 6
#define __NR_waitpid 7
#define __NR_creat 8
#define __NR_link 9
#define __NR_unlink 10
#define __NR_execve 11
#define __NR_chdir 12
#define __NR_time 13
#define __NR_mknod 14
#define __NR_chmod 15
#define __NR_lchown 16
#define __NR_break 17
#define __NR_oldstat 18
#define __NR_lseek 19
#define __NR_getpid 20
#define __NR_mount 21
#define __NR_umount 22
include/asm-generic/unistd.h
#if !defined(_ASM_GENERIC_UNISTD_H) || defined(__SYSCALL)
#define _ASM_GENERIC_UNISTD_H
#include <asm/bitsperlong.h>
/*
* This file contains the system call numbers, based on the
* layout of the x86-64 architecture, which embeds the
* pointer to the syscall in the table.
*
* As a basic principle, no duplication of functionality
* should be added, e.g. we don't use lseek when llseek
* is present. New architectures should use this file
* and implement the less feature-full calls in user space.
*/
#ifndef __SYSCALL
#define __SYSCALL(x, y)
#endif
#if __BITS_PER_LONG == 32
#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _32)
#else
#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _64)
#endif
#define __NR_io_setup 0
__SYSCALL(__NR_io_setup, sys_io_setup)
#define __NR_io_destroy 1
__SYSCALL(__NR_io_destroy, sys_io_destroy)
#define __NR_io_submit 2
__SYSCALL(__NR_io_submit, sys_io_submit)
#define __NR_io_cancel 3
__SYSCALL(__NR_io_cancel, sys_io_cancel)
#define __NR_io_getevents 4
__SYSCALL(__NR_io_getevents, sys_io_getevents)
/* fs/xattr.c */
#define __NR_setxattr 5
__SYSCALL(__NR_setxattr, sys_setxattr)
#define __NR_lsetxattr 6
__SYSCALL(__NR_lsetxattr, sys_lsetxattr)
#define __NR_fsetxattr 7
__SYSCALL(__NR_fsetxattr, sys_fsetxattr)
#define __NR_getxattr 8
__SYSCALL(__NR_getxattr, sys_getxattr)
#define __NR_lgetxattr 9
__SYSCALL(__NR_lgetxattr, sys_lgetxattr)
#define __NR_fgetxattr 10
__SYSCALL(__NR_fgetxattr, sys_fgetxattr)
#define __NR_listxattr 11
__SYSCALL(__NR_listxattr, sys_listxattr)
#define __NR_llistxattr 12
I don't have a definite answer, but it's not uncommon for redundant files to exist when devs try to shift from old mechanisms to newer ones. Your case here looks quite similar.
If you checkout the 3.4 kernel, you will find that both arch/x86/include/asm/unistd_32.h and arch/x86/include/asm/unistd_64.h are gone. Instead, they are generated using arch/x86/syscalls.
Checkout the latest kernel (3.4.2 stable works for me), and do a "git log --stat arch/x86/include/asm", search for unistd_64.h or unistd_32.h or unistd.h.
I found the following commit might be interesting to you.
commit 303395ac3bf3e2cb488435537d416bc840438fcb
I've never touched syscalls before, so I'd rather not say too much. git log is usually how I sort out confusing files. You can also get into makefiles if you are good at it. (I am not, so I rely on git log. )
I'm new to visual c++ and rusty with c++.
I created a dll project following the visual C++ directions. Now I want to test my dll to make sure it's working. I created an empty project and put in tester.cpp. I added the dll to the project references and to the path. Then I try to run it.
Before I included stuff from my dll ("Hello world!") it worked. Now that I've put in my stuff to reference the dll, it fails. The message is:
1>LINK : fatal error LNK1104: cannot open file 'C:\Users\thom\Documents\cworkspace\barnaby\Debug\barnaby.lib'
The thing I don't understand is the reference links to the dll which exists at the path above. Here's my code:
#include <iostream>
#include <string>
#include <vector>
#include "barnaby.h"
int main(int argc, char *argv[]){
std::vector<std::string> tzNames = Barnaby::TimeZoneFunctions::getTimezoneList();
for(std::vector<std::string>::iterator iter = tzNames.begin(); iter != tzNames.end(); iter++){
std::cout << *iter << std::endl;
}
}
ideas?
OK, so I found the answer from http://binglongx.wordpress.com/2009/01/26/visual-c-does-not-generate-lib-file-for-a-dll-project/ which told me to include the following code in my header for the DLL:
#ifdef BARNABY_EXPORTS
#define BARNABY_API __declspec(dllexport)
#else
#define BARNABY_API __declspec(dllimport)
#endif
Then, each function I export you simply precede by:
BARNABY_API int add(){
}
All of this would have been prevented either by click the Export Symbols box on the new project DLL Wizard or by voting yes for lobotomies for application programmers.
Thanks for the help.
Is there something like the ANSI C operator _Pragma in Visual C++?
For example, I'm trying to define the following macro:
#ifdef _OPENMP
#define PRAGMA_IF_OPENMP(x) _Pragma (#x)
#else // #ifdef _OPENMP
#define PRAGMA_IF_OPENMP(x)
#endif // #ifdef _OPENMP
So I can circumvent compiler warnings for unknown #pragma omp ... in older GCC compilers.
Is there a similar means available in VisualC++?
Yes, but it's two underscores: __pragma
I'm not sure about how the omp pragma works, however, here's an example using VC++'s optimize pragma:
#define PRAGMA_OPTIMIZE_OFF __pragma(optimize("", off))
// These two lines are equivalent
#pragma optimize("", off)
PRAGMA_OPTIMIZE_OFF
EDIT: I've just confirmed that the omp pragmas can also be used like this:
#define OMP_PARALLEL_FOR __pragma(omp parallel for)
So, yes, your macro should work if defined as follows (note that your original code incorrectly used the stringizing operator #x:
#ifdef _OPENMP
#define PRAGMA_IF_OPENMP(x) __pragma (x)
#else // #ifdef _OPENMP
#define PRAGMA_IF_OPENMP(x)
#endif // #ifdef _OPENMP