#11 happened because the Mac the author was using didn't have /proc/cpuinfo – there should probably be either (a) an alt name for /proc/cpuinfo or (b) some other way of getting that data out of Macs.

I can't build all because this macro isn't defined apparently, but why? That's why then I get this linker error: LINK : fatal error LNK1104: cannot open file 'lib\Debug\infowared.lib'

Latest version of infoware MSVC2019 Windows10

3>C:\GitHub\infoware\src\pci.cpp(38,34): error C2065: 'INFOWARE_GENERATED_PCI_INDICES': undeclared identifier
3>C:\GitHub\infoware\src\pci.cpp(39,42): error C2065: 'INFOWARE_GENERATED_PCI_VENDORS': undeclared identifier
3>C:\GitHub\infoware\src\pci.cpp(40,42): error C2065: 'INFOWARE_GENERATED_PCI_DEVICES': undeclared identifier

I've used vcpkg and Conan before, but I'm keen to try Hunter or the decentralised Buckaroo https://hackingcpp.com/cpp/tools/package_managers.html

Happy to contribute, just want to know what you want

See the figure below:

ther software displays:

I hope to be updated. Thank you very much.

Maybe I misunderstood the description. The above two pictures are other computers. The picture below is my computer.

My notebook display is correct. Why?

We need a way of finding out more overarching system information not directly related to the internal hardware. May include:

• [x] OS Vendor / Information (Ubuntu, Windows 10, etc.) (Probably going to need a versioning structure for these things too)
• [x] Kernel Information (Linux, Vista, whatever the fuck is inside Mac OSX)
• [x] Monitor/Display Count (kind've stretch, but would be nice, can also include extra information like 'High DPI' and what not)
• [x] Memory (size in bytes)

Fancy:

• [x] # of mice
• [x] # of keyboards

As of now we have them in iware::detail::identify_{vendor,device}(), but moving them to iware::[subsystem]::idenify_pci_{vendor,device}()/pci_{vendor,device}_id() where [subsystem] is system maybe but it's not strictly a discovery method so maybe new data? or straight up pci module? would be nice.

Making a second PR for the installation target as requested

With these additions, when running the installation target (make install), the installation directory will be set with:

├── include
   ├── cpu.hpp
   ├── gpu.hpp
   ├── infoware.hpp
   ├── system.hpp
   └── version.hpp
├── lib
   └── libinfowared.a
└── share
    └── infoware
        ├── infowareConfig-debug.cmake
        ├── infowareConfig.cmake
        └── infowareConfigVersion.cmake

Note: The installation directory can be set with CMAKE_INSTALL_PREFIX, otherwise it will be the default GNU directories on UNIX platforms (/usr/include,/usr/lib )

To choose the headers that will be exported, they have to be labelled as PUBLIC_HEADERS, hence the variable I added and the set_target_properties

The share folder is useful for external projects built with CMake too using the library. Indeed in another project, to use this library, all you have to do then is find_package(infoware) and target_link_libraries(${PROJECT_NAME} PRIVATE infoware). CMake is then handling everything else (Include directories, compile definitions, dependencies).

CMake is creating infowareConfig.cmake that contains the common infos for you project and is creating a config file by build type (infowareConfig-debug.cmake for instance) for specific rules. The infowareConfigVersion.cmake is just here to handle the versions, for instance an external project can do find_package(infoware 1.0) to have a specific version

When doing find_package(infoware) in my project, CMake will take automatically the corresponding library (debug or release), depending on my project's CMAKE_BUILD_TYPE.

The debug postfix I added (notice the d at the end libinfowared) is not mandatory but useful just to know in which mode the library was built (when configured with CMake with CMAKE_BUILD_TYPE).

Got infoware through vcpkg, installed fine. Added to my cmake lists, also ok. Tried to include - compile time errors: Cannot open include file: 'infoware/detail/linkage.hpp': No such file or directory (...).

Looked into vcpkg/packages/infoware_x64-windows/include/infoware, and yeah, there's no detail folder in there.

The windows implementation of iware::cpu::frequency does basically QueryPerformanceFrequency() * 1000 -- which returns completely bogus values. On my machine, QueryPerformanceFrequency returns e.g. 10 MHz, so this reports 10 GHz...

Finding accurate values may be hard, but would it be preferable to return a guesstimate from HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\~MHz (e.g. 3696 on my machine)?

  Quantities:
    Logical CPUs : 8
    Physical CPUs: 0
    CPU packages : 0

  Caches:
    L1:
      Size         : 0B
      Line size    : 0B
      Associativity: 0
      Type         : Unified
    L2:
      Size         : 0B
      Line size    : 0B
      Associativity: 0
      Type         : Unified
    L3:
      Size         : 0B
      Line size    : 0B
      Associativity: 0
      Type         : Unified

  Architecture: x64
  Frequency: 0 Hz
  Endianness: Little-Endian
Segmentation fault: 11

Done on a 2015 15" MacbookPro with 2.2 GHz Core i7 4770HQ cpu.

First it requires me to retarget solution. Afterwards building examples & generator projects fails with these errors:

Severity	Code	Description	Project	File	Line	Suppression State
Error	LNK2019	unresolved external symbol "struct iware::cpu::quantities_t __cdecl iware::cpu::quantities(void)" (?quantities@cpu@iware@@YA?AUquantities_t@12@XZ) referenced in function main	examples	E:\infoware\infoware\cpu.obj	1	
Error	LNK1120	5 unresolved externals	examples	E:\infoware\infoware\x64\Debug\examples.exe	1	
Error	C1083	Cannot open source file: 'pci_generator\src\pci_generator.cpp': No such file or directory	generator	E:\infoware\infoware\c1xx	1	
Warning	MSB8028	The intermediate directory (x64\Debug\) contains files shared from another project (generator.vcxproj).  This can lead to incorrect clean and rebuild behavior.	infoware	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	392	
Warning	MSB8028	The intermediate directory (x64\Debug\) contains files shared from another project (generator.vcxproj, infoware.vcxproj).  This can lead to incorrect clean and rebuild behavior.	examples	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	392	
Warning	MSB8028	The intermediate directory (x64\Debug\) contains files shared from another project (infoware.vcxproj).  This can lead to incorrect clean and rebuild behavior.	generator	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	392	
Warning	MSB8027	Two or more files with the name of non-windows.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are src\cpu\vendor_model_name\non-windows.cpp, src\system\amounts\non-windows.cpp, src\system\kernel_info\non-windows.cpp, src\system\memory\non-windows.cpp, src\system\OS_info\non-windows.cpp.	infoware	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	936	
Warning	MSB8027	Two or more files with the name of non_windows.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are src\cpu\architecture\non_windows.cpp, src\cpu\frequency\non_windows.cpp, src\cpu\instuction_set\non_windows.cpp, src\cpu\quantities_cache\non_windows.cpp.	infoware	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	936	
Warning	MSB8027	Two or more files with the name of windows.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are src\cpu\architecture\windows.cpp, src\cpu\frequency\windows.cpp, src\cpu\instuction_set\windows.cpp, src\cpu\quantities_cache\windows.cpp, src\cpu\vendor_model_name\windows.cpp, src\system\amounts\windows.cpp, src\system\displays\windows.cpp, src\system\kernel_info\windows.cpp, src\system\memory\windows.cpp, src\system\OS_info\windows.cpp.	infoware	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets	936	
Error	LNK2019	unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl iware::cpu::model_name(void)" (?model_name@cpu@iware@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) referenced in function main	examples	E:\infoware\infoware\cpu.obj	1	
Error	LNK2019	unresolved external symbol "enum iware::cpu::architecture_t __cdecl iware::cpu::architecture(void)" (?architecture@cpu@iware@@YA?AW4architecture_t@12@XZ) referenced in function main	examples	E:\infoware\infoware\cpu.obj	1	
Error	LNK2019	unresolved external symbol "struct iware::cpu::cache_t __cdecl iware::cpu::cache(unsigned int)" (?cache@cpu@iware@@YA?AUcache_t@12@I@Z) referenced in function main	examples	E:\infoware\infoware\cpu.obj	1	
Error	LNK2019	unresolved external symbol "__int64 __cdecl iware::cpu::frequency(void)" (?frequency@cpu@iware@@YA_JXZ) referenced in function main	examples	E:\infoware\infoware\cpu.obj	1	

OS_Info.full_name on MacOS gives me information about the kernel (basically uname -a).

On Linux it gives information (name and version) about the distribution, and that looks more coherent.

Shouldn't the MacOS version do something similar, like the output of the sw_vers command?

Hi, was thinking if getting info on Disks, VM's etc. was ever planned or in the works. Specifically looking for something similar to systeminformation

AFAIK that is the most complete info collection tool out there, and if that is done in Node.js. I think all that is definitely possible with C++.

I currently try to compile infoware on aarch64. But on all tried distribution the <cpuid.h> is missing. (debain for arm, raspberry OS) In this source the header is referenced. Is there a possibility to add support for aarch64?

Both projects are starting to wind down open source support so it's time to find other alternatives.

And by other alternatives I mean GITHUB ACTIONS BAYBEEE.

The Carbon/Quartz API says it only supports:

The refresh rate, in hertz, of the specified display mode for a CRT display. Some displays may not use conventional video vertical and horizontal sweep in painting the screen; for these displays, the return value is 0.

It'd be lovely to circumvent that somehow

Previous instalments: #22, #17