switch port for ipp printer - windows

I need to change the port of an ipp printer using powershell or any other form of command/script
I tried to create and switch Port like this:
Add-PrinterPort -name "newport" --PrinterHostAddress "http://{the new ip}"
Set-Printer -name "myPrinterName" -PortName "newPort"
but the printer doesn't get the new printing jobs after this.
I checked and the old port and the new port are different,
the command Get-PrinterPort | select * shows this for the two port:
Caption :
Description : Internet Port
ElementName :
InstanceID :
CommunicationStatus :
DetailedStatus :
HealthState :
InstallDate :
Name : http://{the printer ip}
OperatingStatus :
OperationalStatus :
PrimaryStatus :
Status :
StatusDescriptions :
ComputerName :
PortMonitor : Internet Port
PSComputerName :
CimClass : ROOT/StandardCimv2:MSFT_PrinterPort
CimInstanceProperties : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
Protocol : RAW
Caption :
Description : Standard TCP/IP Port
ElementName :
InstanceID :
CommunicationStatus :
DetailedStatus :
HealthState :
InstallDate :
Name : newPort
OperatingStatus :
OperationalStatus :
PrimaryStatus :
Status :
StatusDescriptions :
ComputerName :
PortMonitor : TCPMON.DLL
LprByteCounting : False
LprQueueName :
PortNumber : 9100
PrinterHostAddress : {the new ip address}
PrinterHostIP :
SNMPCommunity :
SNMPEnabled : False
SNMPIndex : 0
PSComputerName :
CimClass : ROOT/StandardCimv2:MSFT_TcpIpPrinterPort
CimInstanceProperties : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
How can I create a new "internet port" ?
I checked all the docs,forums,etc.. I could but didn't find anything about it.
I know the "internet Port" is created automatically when i created my printer with this command: Add-Printer -Name "myPrinter" -DriverName "driverName" -PortName "http://{the ip for the printer}"

Related

How to fix call FwpmEngineOpen function caused BSOD on windows 11 22h2

I recently encountered the problem of calling FwpmEngineOpen method on windows 11 22h2 system causing BSOD. Not every windows 11 22h2 laptop will experience this problem. But the laptop with the problem, it reproduces the problem every time.
I tried to reinstall windows 11 21h2 on the faulty device. Failed to reproduce the BSOD problem. Then upgrade to 22H2 using the latest windows 11 ISO, which can reproduce the BSOD. So I guess the problem only exists at windows 11 22H2.
The dump is:
Microsoft (R) Windows Debugger Version 10.0.22621.382 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\melon\Desktop\BSOD\22017068\121222-10750-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Path validation summary **************
Response Time (ms) Location
Deferred SRV*E:\WindowsPDB*http://msdl.microsoft.com/download/symbols
OK C:\Users\melon\Desktop\BSOD\06202019\win8_release
Symbol search path is: SRV*E:\WindowsPDB*http://msdl.microsoft.com/download/symbols;C:\Users\melon\Desktop\BSOD\06202019\win8_release
Executable search path is:
Windows 10 Kernel Version 22621 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0xfffff802`61200000 PsLoadedModuleList = 0xfffff802`61e13410
Debug session time: Mon Dec 12 17:46:26.125 2022 (UTC + 8:00)
System Uptime: 0 days 1:16:03.795
Loading Kernel Symbols
...............................................................
................................................................
................................................................
..........................................
Loading User Symbols
Loading unloaded module list
........................
For analysis of this file, run !analyze -v
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
BugCheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff8025d4c4e70
Arg3: ffffe48d45e4bfb0
Arg4: fffff802614bea11
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for apegw.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2217
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 3200
Key : Analysis.Init.CPU.mSec
Value: 2671
Key : Analysis.Init.Elapsed.mSec
Value: 114150
Key : Analysis.Memory.CommitPeak.Mb
Value: 113
FILE_IN_CAB: 121222-10750-01.dmp
DUMP_FILE_ATTRIBUTES: 0x1008
Kernel Generated Triage Dump
BUGCHECK_CODE: 7f
BUGCHECK_P1: 8
BUGCHECK_P2: fffff8025d4c4e70
BUGCHECK_P3: ffffe48d45e4bfb0
BUGCHECK_P4: fffff802614bea11
STACK_OVERFLOW: Stack Limit: ffffe48d45e4c000. Use (kF) and (!stackusage) to investigate stack usage.
STACKUSAGE_FUNCTION: The function at address 0xfffff802731d1809 was blamed for the stack overflow. It is using 13888 bytes of stack.
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: SA2.0QuestUpda
STACK_TEXT:
ffffe48d`45e4bfb0 fffff802`614c20c4 : 00000000`00000000 0b030000`00000157 00000000`00000021 00000521`00000521 : nt!KiDeferredReadySingleThread+0x41
ffffe48d`45e4c380 fffff802`614b39c2 : 000005c7`000005c7 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExitDispatcher+0x184
ffffe48d`45e4c720 fffff802`614b3294 : ffffa989`00000000 ffffa989`2a2a9768 00000000`0000000c 00000000`00000000 : nt!KeInsertPriQueue+0x5a2
ffffe48d`45e4c7b0 fffff802`619dbb56 : 00000000`00000001 00000000`00000000 00000000`00000000 ffff8082`8302d370 : nt!ExQueueWorkItem+0x164
ffffe48d`45e4c810 fffff802`61957e4f : 00000000`00000001 00000000`00000000 ffff8082`8302d370 00000000`00000000 : nt!ExpWnfStartKernelDispatcher+0x3e
ffffe48d`45e4c840 fffff802`61955e16 : ffff8082`8302d300 00000000`00000000 ffffe48d`00000001 00000000`00000000 : nt!ExpWnfNotifyNameSubscribers+0x177
ffffe48d`45e4c8b0 fffff802`61955b4e : 00000605`00000605 00000000`00000000 000002e5`22f25990 000002e5`22eff960 : nt!ExpNtUpdateWnfStateData+0x2ba
ffffe48d`45e4c9c0 fffff802`6163d1e8 : ffff8082`84a8e000 fffff802`614d2615 ffffffff`ffffffff 00000000`0000001c : nt!NtUpdateWnfStateData+0x2e
ffffe48d`45e4ca10 fffff802`6162dc50 : fffff802`618a4736 00000000`00000001 00000000`00000001 00000000`00000006 : nt!KiSystemServiceCopyEnd+0x28
ffffe48d`45e4cc18 fffff802`618a4736 : 00000000`00000001 00000000`00000001 00000000`00000006 00000000`00000000 : nt!KiServiceLinkage
ffffe48d`45e4cc20 fffff802`619e378c : ffff8082`94580e00 fffff802`00000000 ffff8082`00000006 00000000`00002758 : nt!PspChargeProcessWakeCounter+0x366
ffffe48d`45e4ccd0 fffff802`61a8e1fe : 00000000`00000000 ffffa989`3f07cdf0 ffff8082`94659b50 00000000`00000000 : nt!PsChargeProcessWakeCounter+0x4c
ffffe48d`45e4cd20 fffff802`618a5ce1 : ffff8082`94659b00 ffffa989`3f330830 ffffa989`3238f940 00000000`00000000 : nt!AlpcpCompleteDispatchMessage+0x1e80fe
ffffe48d`45e4cde0 fffff802`618a5a12 : ffffa989`3238f940 ffffa989`3f07cdf0 00000000`00000000 00000000`00000000 : nt!AlpcpDispatchNewMessage+0x291
ffffe48d`45e4ce40 fffff802`618a9480 : ffffe48d`45e4cff0 ffff8082`900ff000 ffff8082`944094f0 fffff802`614be800 : nt!AlpcpSendMessage+0x922
ffffe48d`45e4cf70 fffff802`618a6c99 : ffffa989`3f330830 00000000`00220000 ffff8082`900ff000 ffff8082`944094f0 : nt!AlpcpProcessSynchronousRequest+0x330
ffffe48d`45e4d090 fffff802`6163d1e8 : ffffa989`39273080 ffffe48d`45e4d240 ffffe48d`45e4d378 ffffe48d`45e4d168 : nt!NtAlpcSendWaitReceivePort+0x1d9
ffffe48d`45e4d150 fffff802`6162dc50 : fffff802`62c5bcfe ffff8082`900ff000 00000000`00000000 ffff8082`94409480 : nt!KiSystemServiceCopyEnd+0x28
ffffe48d`45e4d358 fffff802`62c5bcfe : ffff8082`900ff000 00000000`00000000 ffff8082`94409480 ffff8082`944095f8 : nt!KiServiceLinkage
ffffe48d`45e4d360 fffff802`62c5bc12 : 00000000`00001000 ffff8082`94409480 ffffe48d`45e4d600 fffff802`62c4a0d0 : msrpc!LRPC_BASE_CCALL::DoSendReceive+0x72
ffffe48d`45e4d3d0 fffff802`62c5c5fb : 00000000`00000000 ffffe48d`45e4d470 00000000`00000000 fffff802`62c434f0 : msrpc!LRPC_BASE_CCALL::SendReceive+0x52
ffffe48d`45e4d400 fffff802`62c42435 : ffffe48d`45e4d6c0 00000000`00000000 fffff802`62c434f0 00000000`00000000 : msrpc!NdrSendReceive+0x47
ffffe48d`45e4d430 fffff802`62c42313 : 00000000`00000000 fffff802`62c434f0 fffff802`00000007 ffffe48d`45e4d460 : msrpc!NdrpClientCall3+0xf5
ffffe48d`45e4d680 fffff802`62c6e589 : 00000000`00000000 ffffa989`39273080 00000000`00000000 ffff8082`9460d550 : msrpc!NdrClientCall3+0x93
ffffe48d`45e4da20 fffff802`62c6e3c5 : ffff8082`9392cb20 ffff8082`94610100 00000000`00000000 00000000`00000000 : msrpc!EP_LOOKUP_DATA::LookupNextChunk+0x11d
ffffe48d`45e4daf0 fffff802`62c6e8f5 : 00000000`00000000 00000000`00000000 ffff8082`94610100 ffffe48d`45e4dd70 : msrpc!EP_LOOKUP_DATA::ResolveEndpoint+0x135
ffffe48d`45e4db80 fffff802`62c6e86e : ffff8082`94610070 00000000`00000000 ffff8082`94610100 fffff802`62c6e198 : msrpc!ResolveEndpointWithEpMapper+0x6d
ffffe48d`45e4dbe0 fffff802`62c6e0d1 : ffff8082`94610070 00000000`00000000 ffff8082`94610100 fffff802`614c8d40 : msrpc!ResolveEndpointIfNecessary+0xa6
ffffe48d`45e4dc60 fffff802`62c6dfab : 00000000`00000000 00000000`00000000 ffff8082`94610070 00000000`00000000 : msrpc!LRPC_BASE_BINDING_HANDLE::SubmitResolveEndpointRequest+0xcd
ffffe48d`45e4dcf0 fffff802`62c690a1 : 00000000`00000000 ffff8082`94610070 fffff802`642cd000 ffff8082`9464bd90 : msrpc!LRPC_BASE_BINDING_HANDLE::ResolveEndpoint+0xeb
ffffe48d`45e4dd70 fffff802`62c68717 : ffff8082`94610070 ffff8082`94610070 ffffe48d`45e4de39 00000000`00000000 : msrpc!LRPC_BASE_BINDING_HANDLE::DriveStateForward+0x2a1
ffffe48d`45e4ddd0 fffff802`62c6b22d : 00000000`00000000 00000000`00000000 00000000`00000000 ffff8082`9464bd90 : msrpc!LRPC_FAST_BINDING_HANDLE::Bind+0x137
ffffe48d`45e4dea0 fffff802`642fa0f8 : 00000000`00000000 ffff36b4`d7ae09c0 00000000`00000001 ffffa989`3acce920 : msrpc!RpcBindingBind+0x2d
ffffe48d`45e4ded0 fffff802`642f9f05 : ffffe48d`45e4dff0 fffff802`00000040 00000000`00000000 00000000`00000000 : fwpkclnt!FwppRpcBindingBind+0x1c
ffffe48d`45e4df00 fffff802`642f9e26 : ffffe48d`45e4dff0 00000000`00000000 ffffffff`ffffffff fffff802`61589421 : fwpkclnt!FwppSessionCreate+0xb9
ffffe48d`45e4df70 fffff802`731d1338 : 00000000`c0000001 ffffe48d`45e517a1 00000000`00000000 00000000`00000000 : fwpkclnt!FwpmEngineOpen0+0x56
ffffe48d`45e4dfb0 fffff802`731d11b8 : fffff802`731d3520 00000000`00000000 00000000`00000000 ffffa989`2e8e28f0 : apegw!OpenEngine+0x4c [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 616]
ffffe48d`45e4e060 fffff802`731d1428 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffa989`383c9000 : apegw!InitWfp+0x28 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 313]
ffffe48d`45e4e090 fffff802`731d1809 : 00000000`00000000 fffff802`6143e34c 00000000`00000000 ffffe48d`45e4e159 : apegw!RuleEngineStart+0x10 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 29]
ffffe48d`45e4e0c0 fffff802`614cb875 : ffffa989`30172bd0 fffff802`618c2677 ffffe48d`45e517a1 00000000`00000002 : apegw!WfpIRPDispatch+0x149 [c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c # 180]
ffffe48d`45e51700 fffff802`618c2c70 : ffffa989`30172bd0 ffffe48d`45e517a1 ffffa989`30172bd0 ffffa989`382210f0 : nt!IofCallDriver+0x55
ffffe48d`45e51740 fffff802`618c123c : 00000000`00000000 00000000`0022e024 ffffe48d`45e51b60 ffffa989`30172bd0 : nt!IopSynchronousServiceTail+0x1d0
ffffe48d`45e517f0 fffff802`618bf516 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x72c
ffffe48d`45e51a00 fffff802`6163d1e8 : 00000000`00000544 000000c8`12ffdcd8 000000c8`12ffdcd0 00000000`00000008 : nt!NtDeviceIoControlFile+0x56
ffffe48d`45e51a70 00007ffe`4e96eee4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000c8`12ffe448 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`4e96eee4
FAULTING_SOURCE_LINE: c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c
FAULTING_SOURCE_FILE: c:\devops\sa\src\features\assessmenttaking\assessmenttaking.apeg\apeg_win_dylib\apegw\firewall.c
FAULTING_SOURCE_LINE_NUMBER: 180
SYMBOL_NAME: apegw!WfpIRPDispatch+149
MODULE_NAME: apegw
IMAGE_NAME: apegw.sys
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 149
FAILURE_BUCKET_ID: 0x7f_8_STACK_USAGE_apegw!WfpIRPDispatch
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {286d046a-caea-634c-9c2e-ffb90d719cec}
Followup: MachineOwner
---------
Here is the sample code which can reproduce this issue on the laptop with the problem. By the way, if I comment the code in file firewall.c which locate in test_driver from line 176 to line 184, issue disappear.
sample code: https://1drv.ms/u/s!AoZBPdtrfQp1hAMIkW0MgVcq7sVJ?e=AWklwy

Path.getNameCount returns 1 if even if Path.get("") is just an empty string

It really does not makes sense why the console output is a bit inconsistent for Path.getNameCount whenever Path.get("").getNameCount() returns 1 wherein I expect it to be 0, when I use Path.get("C:\").getNameCount() returns 0 -> this one works as expected. I read the javadoc, there not much of an intuitive info about what happen so I have to ask is this something that needs fixing in java se? or I am missing something?
From java doc:
int getNameCount()
Returns the number of name elements in the path.
Returns:
the number of elements in the path, or 0 if this path only represents a root component
//omitted codes
print(Paths.get(""));
print(Paths.get("C:"));
print(Paths.get("C:\\"));
//omitted codes
public static void print(Path path) {
System.out.println("~~~~~~~ " + path + " ~~~~~~~");
System.out.println("getRoot : " + path.getRoot());
System.out.println("getParent : " + path.getParent());
System.out.println("getFileName : " + path.getFileName());
int nameCount = path.getNameCount();
System.out.println("getNameCount : " + nameCount);
if (nameCount > 1) {
IntStream.range(0,nameCount).forEach(x->{
System.out.println("getName(" + x + ") : " + path.getName(x) + "\t");
});
}
}
//omitted codes
Console Output:
~~~~~~~ ~~~~~~~
getRoot : null
getParent : null
getFileName :
getNameCount : 1
~~~~~~~ C: ~~~~~~~
getRoot : C:
getParent : null
getFileName : null
getNameCount : 0
~~~~~~~ C:\ ~~~~~~~
getRoot : C:\
getParent : null
getFileName : null
getNameCount : 0
Thanks to #Thilo, I realized that Paths.get("") is equivalent to the default directory or the current directory and as per specification I wont get 0 from getNameCount but 1, so I ran some test
System.out.println("isAbsolute : " + path.isAbsolute());
System.out.println("toAbsolutePath : " + path.toAbsolutePath());
console output:
isAbsolute : false
toAbsolutePath : C:\Users\user\Documents\java\NIO
so there, that makes sense now.is was never an empty path after all, but ofcourse toAbsolutePath return new Path object and is not equal to the original Path("")

Search-Mailbox cmdlet in Exchange 2013

I sent a email from administrator to a user usertest4 with title and body: 'aaaaaaa'.
Waiting 5 minutes then i execute this script:
Search-Mailbox -Identity 'usertest4' -SearchQuery {(From:"*admin*" AND Body:"*h*" AND Received<= "05/16/2021 05:16")} -EstimateResultOnly -Confirm:$False -Force:$true
Result return:
RunspaceId : 1e48d0dd-77b1-4dcd-9178-257fc511832c
TargetMailbox :
Success : True
TargetFolder :
ResultItemsCount : 0
ResultItemsSize : 0 B (0 bytes)
When i'm changed EstimateResultOnly to DeleteContent, it delete this email in usertest4's mailbox then return result:
RunspaceId : 1e48d0dd-77b1-4dcd-9178-257fc511832c
TargetMailbox :
Success : True
TargetFolder :
ResultItemsCount : 1
ResultItemsSize : 6.799 KB (6,962 bytes)
Something wrong here?
Why EstimateResultOnly return 0 but DeleteContent return 1?

.net memory usage reporting difference between task manager and windbg/sos

I have a .net application. In task manager it showing 249 MB usage in Memory (private working set) column. Then I attach windb and ran !address –summary command. Below is its result. The memory usage its showing in .NET heap(RegionUsageIsVAD) is 568 MB.
Should these two values be same? Can anyone explain why is so much difference between the two values?
-------------------- Usage SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Pct(Busy) Usage
22b7c000 ( 568816) : 27.12% 64.42% : RegionUsageIsVAD
4a1b3000 ( 1214156) : 57.90% 00.00% : RegionUsageFree
e8e6000 ( 238488) : 11.37% 27.01% : RegionUsageImage
1c00000 ( 28672) : 01.37% 03.25% : RegionUsageStack
0 ( 0) : 00.00% 00.00% : RegionUsageTeb
2dda000 ( 46952) : 02.24% 05.32% : RegionUsageHeap
0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap
1000 ( 4) : 00.00% 00.00% : RegionUsagePeb
0 ( 0) : 00.00% 00.00% : RegionUsageProcessParametrs
0 ( 0) : 00.00% 00.00% : RegionUsageEnvironmentBlock
Tot: 7fff0000 (2097088 KB) Busy: 35e3d000 (882932 KB)
-------------------- Type SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
4a1b3000 ( 1214156) : 57.90% :
11ce9000 ( 291748) : 13.91% : MEM_IMAGE
9fe9000 ( 163748) : 07.81% : MEM_MAPPED
1a16b000 ( 427436) : 20.38% : MEM_PRIVATE
-------------------- State SUMMARY --------------------------
TotSize ( KB) Pct(Tots) Usage
2e2a0000 ( 756352) : 36.07% : MEM_COMMIT
4a1b3000 ( 1214156) : 57.90% : MEM_FREE
7b9d000 ( 126580) : 06.04% : MEM_RESERVE
Largest free region: Base 32ce9000 - Size 15377000 (347612 KB)
!address is just showing you address space usage. Some of the memory is paged out. The working set (memory actually paged in and in use) is much smaller.

How can I get bjam to find my .h files in other directories

I'm maintaining this solution in Visual Studio 2008, but I build my deliverables with bjam.
The solution includes 3 projects.
jamfiles are setup to build 2 versions of the solution (say A and B), and then 32-bit and 64-bit executables for each version.
My problem is that bjam is not finding the .h files for one of the projects in the solution, generating the error below. These .h files are physically located 2 directories up and one down in an "include" folder.
If I copy the .h files to where the project's jamfile is located, the errors go away, and the solution builds perfectly. However, we must keep the .h files in the "include" folder.
My question is, how do I instruct bjam to look for .h files in the "include" folder?
Below is the jamfile for the problematic project, and my site-config.jam file
Any hints will be much appreciated. Thanks.
-----------------------------------
ERROR:
compile-c-c++ Utilities\TemperatureLog\bin\msvc-9.0\small_x86\threading-multi\user-interface-gui\TemperatureLog.obj
TemperatureLog.cpp
c:\winirdir\build\winir\utilities\temperaturelog\TemperatureLogDlg.h(50) : error C2653: 'SBF' : is not a class or namespace name
c:\winirdir\build\winir\utilities\temperaturelog\TemperatureLogDlg.h(50) : error C2143: syntax error : missing ';' before '*'
c:\winirdir\build\winir\utilities\temperaturelog\TemperatureLogDlg.h(50) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
c:\winirdir\build\winir\utilities\temperaturelog\TemperatureLogDlg.h(50) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
------------------------------------------
JAMFILE:
project temperaturelog :
: requirements <define>_AFXDLL
<user-interface>gui
:
;
sources = [ glob *.cpp ] TemperatureLog.rc ;
exe TemperatureLog$(suffix) : $(sources)
/sbfsdk//SbfSdk$(suffix)
:
: small_x86
;
exe TemperatureLog$(suffix)_x64 : $(sources)
/sbfsdk//SbfSdk$(suffix)_x64
:
: small_x64
;
exe TemperatureLog$(suffix)_sap : $(sources)
/sbfsdk//SbfSdk$(suffix)_sap
:
: smallSapera_x86
;
exe TemperatureLog$(suffix)_sap_x64 : $(sources)
/sbfsdk//SbfSdk$(suffix)_sap_x64
:
: smallSapera_x64
;
install dist_x86 : TemperatureLog$(suffix) :
<variant>small_x86 : <location>$(installRoot_x86) ;
install dist_x64 : TemperatureLog$(suffix)_x64 :
<variant>small_x64 : <location>$(installRoot_x64) ;
install dist_sap_x86 : TemperatureLog$(suffix)_sap :
<variant>smallSapera_x86 : <location>$(installRoot_x86) ;
install dist_sap_x64 : TemperatureLog$(suffix)_sap_x64 :
<variant>smallSapera_x64 : <location>$(installRoot_x64) ;
--------------------------------
site-config.jam
project site-config ;
path-constant BoostRoot : C:/Boost/boost_1_44_0 ;
lib shlwapi : : <name>shlwapi ;
lib advapi32 : : <name>advapi32 ;
lib gdi32 : : <name>gdi32 ;
lib user32 : : <name>user32 ;
lib ole32 : : <name>ole32 ;
lib vfw32 : : <name>vfw32 ;
lib delayimp : : <name>delayimp ;
lib gdiplus : : <name>gdiplus ;
lib strmiids : : <name>strmiids ;
lib winmm : : <name>winmm ;
lib msvcrt : : <name>msvcrt ;
lib atls : : <name>atls ;
lib ksproxy : : <name>ksproxy ;
lib kernel32 : : <name>kernel32 ;
lib oleaut32 : : <name>oleaut32 ;
lib uuid : : <name>uuid ;
lib htmlhelp : : <name>htmlhelp ;
lib version : : <name>version ;
lib msi : : <name>msi ;
path-constant PleoraRoot : "C:/Program Files (x86)/Pleora Technologies Inc/iPORT Software" ;
lib cyutilslib_x86 : : <name>CyUtilsLib <search>$(PleoraRoot)/Libraries
:
: <include>$(PleoraRoot)/Includes
;
lib cyutilslib_x64 : : <name>CyUtilsLib64 <search>$(PleoraRoot)/Libraries
:
: <include>$(PleoraRoot)/Includes
;
path-constant PdvRoot : "C:/EDT/pdv" ;
lib pdvlib_x86 : : <name>pdvlib <search>$(PdvRoot)/lib/x86
:
: <include>$(PdvRoot)
;
lib pdvlib_x64 : : <name>pdvlib <search>$(PdvRoot)/lib/amd64
:
: <include>$(PdvRoot)
;
path-constant VceRoot : "C:/Program Files/Imperx/FrameLink Express/SDK" ;
lib vceclb_x86 : : <name>vceclb <search>$(VceRoot)/lib/win32
:
: <include>$(VceRoot)/inc
;
lib vceclb_x64 : : <name>vceclb <search>$(VceRoot)/lib/x64
:
: <include>$(VceRoot)/inc
;
path-constant DirectXRoot : "C:/Program Files (x86)/Microsoft DirectX SDK (June 2010)" ;
lib d3dx9_x86 : : <name>d3dx9 <search>$(DirectXRoot)/Lib/x86
:
: <include>$(DirectXRoot)/Include
;
lib d3dx9_x64 : : <name>d3dx9 <search>$(DirectXRoot)/Lib/x64
:
: <include>$(DirectXRoot)/Include
;
lib d3d9_x86 : : <name>d3d9 <search>$(DirectXRoot)/Lib/x86
:
: <include>$(DirectXRoot)/Include
;
lib d3d9_x64 : : <name>d3d9 <search>$(DirectXRoot)/Lib/x64
:
: <include>$(DirectXRoot)/Include
;
path-constant IfcRoot : "C:/IFC510" ;
lib ifc21 : : <name>ifc21 <search>$(IfcRoot)/lib
:
: <include>$(IfcRoot)/include
;
path-constant PythonRoot : "C:/Required_Binaries/Python-2.7.1" ;
lib python_x86 : : <name>python27 <search>$(PythonRoot)/PCBuild
:
: <include>$(PythonRoot)/Include <include>$(PythonRoot)/PC
;
lib python_x64 : : <name>python27 <search>$(PythonRoot)/PCBuild/amd64
:
: <include>$(PythonRoot)/Include <include>$(PythonRoot)/PC
;
# path-constants work up to here, but not after this, so we use the full path. Why??
path-constant DirectShowRoot : "C:/Program Files/Microsoft SDKs/Windows/v7.0/Samples/multimedia/directshow/baseclasses" ;
lib Strmbase_x86 : : <name>strmbase <search>"C:/Program Files/Microsoft SDKs/Windows/v7.0/Samples/multimedia/directshow/baseclasses/Release_MBCS"
:
: <include>$(DirectShowRoot)
;
lib Strmbase_x64 : : <name>strmbase <search>"C:/Program Files/Microsoft SDKs/Windows/v7.0/Samples/multimedia/directshow/baseclasses/x64/Release_MBCS"
:
: <include>$(DirectShowRoot)
;
path-constant SaperaRoot : "C:/DALSA/Sapera" ;
lib SapClassBasic_x86 : : <name>SapClassBasic <search>"C:/Dalsa/Sapera/Lib/Win32"
:
: <include>$(SaperaRoot)/Classes/Basic <include>$(SaperaRoot)/Include
;
lib SapClassBasic_x64 : : <name>SapClassBasic <search>"C:/Dalsa/Sapera/Lib/Win64"
:
: <include>$(SaperaRoot)/Classes/Basic <include>$(SaperaRoot)/Include
;
path-constant SbfSdkInc : "C:\WinIRDir\build\WinIR\SbfSdk\include" ;
path-constant ActRoot : "C:/Program Files (x86)/Active Silicon/Phoenix/Win/SDK6.47" ;
lib ActiveSilicon_x86 : : <name>phxlw32 <search>$(ActRoot)/Lib/win32
:
: <include>$(ActRoot)/Include
;
lib ActiveSilicon_x64 : : <name>phxlx64 <search>$(ActRoot)/Lib/win64
:
: <include>$(ActRoot)/Include
;
Try something like this with your first exe rule:
exe TemperatureLog$(suffix)
: $(sources)
/sbfsdk//SbfSdk$(suffix)
: <include>../../include
: small_x86
;
More details can be found here
If that works, then instead of duplicating it for every exe rule, you may be able to move it into the project rule with:
project temperaturelog
: requirements
<define>_AFXDLL
<user-interface>gui
<include>../../include
;
Then it should apply to all rules invoked as part of this project.

Resources