|
Context:
I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not.
Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things.
So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
We have one symbol that may be defined in our project files: ENGINEERING. We have build configurations that define the symbol and can be used in source code for engineering-specific builds. These are used for experiments or prototyping logic before a production implementation. We avoid defining symbols in project files otherwise, since it's easy to lose a definition when changing configurations.
Our stdafx.h files #define conditional compilation values like WINVER and #include 'fixed' header files for the C++ runtime, MFC, and so on. These are files where using precompiled headers improve compile times. It will also #include a file that defines the application version and build number, software title, copyright and trademark statements, and so on. This ensures that every executable file, DLL or EXE, gets the same information in the version resource.
Conditional compilation symbols and manifest constants tend to be defined centrally. For a class, that's in the header file for the class. If the element is built from several classes in separate source files, they're in a separate header for the element. If a value is used throughout the project, it will typically be in stdafx.h.
Software Zen: delete this;
|
|
|
|
|
Never in the project file. I've been bitten in my behind too many times by symbols that were or were not defined in different project/configurations that I'll never do that again. If the project has more than a few global defines, they go to a file called defs.h.
Mircea
|
|
|
|
|
Okay, so I had another thought to dig into this deeper.
I agree and understand what has been said, especially the part about avoiding stdafx.h changes. However, there are times when changes must happen, especially when building for CE and WEC7. The part that bothers me is that in my solution I have 60+ stdafx.h files - one for every project. Obviously, for a given build they should all be the same. Because of this problem, it sort of makes sense to push some settings to a prop file or something (I've been reading).
Under no circumstances should application defines be in the project settings unless target related, and even that I might be able to work around.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I've had no end of issues with Microsoft and C++, whether it was their compiler being weird or Visual Studio causing me headaches.
In the end I moved over to VS Code and I build my own "project files" (which are not project files but rather CMake build scripts but they do what I need)
Sorry I can't be more help. I eventually gave up on the approach you took with your project.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
understand. back in my unix days, makefiles were the way to go.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
oh it gets better. So one part of my solution has a project with 15 subprojects. If I build each subproject separately, no errors. Build the project as a whole? Nope, issues out the kazoo.
I feel I'm getting closer though.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
We have a server at work running a big Java application and the Java runtime process is hogging all the CPU time. It doesn't do this on a different server.
I've only ever heard bad things about Java, but I wonder if anyone here has seen such behavior from other Java processes?
There is also suspicious network activity, with about 20 Mbps constant going in and out of the box.
The administrator of the box thinks that's normal server network activity, but I'm worried it might be a bot node. Maybe even part of the network that attacked CP! 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Time to dig out the network analysis tools. Where's the connections going to/coming from? Is the IP port one that would be expected (e.g. HTTPS), or is it something unexpected (e.g random port number at both ends). If you can capture the packets and they're not encrypted, does the data look like what you'd expect?
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Richard Andrew x64 wrote: The administrator of the box thinks that's normal server network activity
Were they break out in a sweat when they said that? 
A network analyzer would be the thing to use here, the capture need not be very long at 20Mbps.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Assuming it's not a rogue bot/application on the server...
Richard Andrew x64 wrote: It doesn't do this on a different server.
I'm not a fan of Java, but if this is the case then my first line of attack would be to assume it's not the JRE or application then (necessarily). It may be a bug that only surfaces with a certain configuration / environment, but it's safe to assume the application is "working" (ish).
So, I would start looking at environmental and configuration differences to see what the deal is. Are these machines in different subnets? Are you certain they are configured exactly the same? Was this a manual server provision (and open to mistakes) or automated? Is it the same exact OS with the same exact kernel version? Is the room's ambient temp the same for both servers? Do you know for certain it's the same exact application version and runtimes on both machines? Is one server in a faraday cage (kidding, well maybe not)? And so on...
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm not a fan of Java, but if this is the case then my first line of attack would be to assume it's not the JRE or application then (necessarily).
I agree here. It uses Java 8, which I have been reading is very well tested and patched. But also, I'm sure there are still vulnerabilities.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The Windows Event Logs might show you something. It shows (bot) login attempts (Security log) and errors (Application log).
In my experience, "all" public servers get "probed" 24/7.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I have 10 years at least each in Java, C# and C++.
There is nothing wrong with Java. Nor with the other two.
What you are describing is what I would generally diagnose as an environment problem.
But could be a data caused problem in that a message(s)/request(s) that should have run to completion did not and now it is just spinning. Restarting it would likely demonstrate that. That however would also indicate a likely programming bug.
Sufficient execution flow logging, in any type of server application, would allow you to diagnose execution flows running out of control.
|
|
|
|
|
New job.
Obviously the first time I'm on watch for the release pipeline, the bloody installer failed.
I'm cursed.
Every time I think about anything related to installers, something will break.
I HATE THIS!
Also, it works on my machine, but not on my colleague machine.
sigh, just shoot me out of my misery. (don't)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I bet something wasn't configured correctly on your machine that the rest of them all know about but it has been so long since anyone had to configure a system they have forgotten.
Ask them, was there anything weird about when you configured your system? It might help.
Then again, if they are using VMs for that I am talking out of my hat.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
Maximilien wrote: Every time I think about anything related to installers, something will break.
Installers shouldn't be any less robust than your application code. This is a hard lesson we learned after using several different installer tools: InstallShield, Wise, and more than one MSI package. We now use Inno Setup exclusively. While it is somewhat less capable than the other tools, it is predictable.Maximilien wrote: it works on my machine, but not on my colleague machine
Our product runs on an industrial PC for which we create the system image. A common test for us is to re-image a machine and then install the product application to ensure all dependencies are installed properly. In a more general-purpose environment it's harder to manage dependencies. You have to contend with variable end-user environments plus a wider variety of Windows versions. The user may have newer versions of something installed that you depend on. It takes a lot of tedious testing to make sure all of the use-cases are covered.Maximilien wrote: I HATE THIS!
Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures.
You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
Software Zen: delete this;
|
|
|
|
|
Quote: We now use Inno Setup exclusively.
I second Inno setup, it's robust and I prefer software that works like a tank over all the clever brittle software.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Quote: Part of my role as the DSJB (Departmental Sh!t-Job Boy) is to do our installers. Before I took them over they were sloppy and unreliable. No one person took care of them. They exhibited the problems you cited and more. Routinely they came with instructions that had to be performed manually to get the application to work. Many bug reports for the products were due to installation failures.
You're not going to like this, but treating the installer like a first-level part of the product fixes a lot of issues.
AMEN! I do software repack and deployment. I have to deal with at least one bad installer a week, and it doesn't matter what it was built with. I can't tell you how many times I've called up vendors and asked them "what the hell are you doing mate?" Time and time again, there's only one person building the installers and, like you said, it's always up to the "DSJB".
I've even had installers that work fine on install, but on uninstall, they treat the customer machine like a $2 whore. "WMI Providers? Nuke 'em. What do you mean we just killed your SCCM deployment system on your machine?"
|
|
|
|
|
> they treat the customer like a $2 whore
Oh man, I have got to use that line in a meeting some time. 
Software Zen: delete this;
|
|
|
|
|
It never worked in the first place. They just said it did ... waiting for the "new guy" to fix it ... 
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I learnt there is one thing I should never do: upgrade the firmware of my hardware.
Everyobne does it and it works flawlessly. I do it, something critical breaks.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
|
OK. I asked before so this is a repost... (so sue me...)
Is there a plain (text) editor which can remove empty lines ?
It would be nice to add as "plug in" into my "development tool"...
Thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
