|
Context: Windows Server 2012 64 bit, everything else is 32 bit.
So, I have a very simple application using tcpip that has worked fine for years. This application exists in the structure of another var application. Using a config file, the var knows to launch my code and connect - it's the way the var allows 3rd parties to extend services. In the environment that works, the oem app and mine runs in user space (see note below). From the user application window, I launch it, everything starts, like is good. It's worked for decades.
In present time, I need to start the oem app as a service. The app starts, launches my application (app runs under a service account) where upon my app C000005s to death. No code has changed. C00005 exceptions are usually obvious to track down - look for the smoking hole in the ground. This one is a little sneaky since it's a few degrees off from my keyboard.
I have an assert and a DebugAssert athe very beginning of my application - c5s and no prompts.
If I launch my app from my command line - it starts and waits on the socket connection.
-----------------------------------------
So any ideas how to catch my app/service starting up? Can I add code to the app? My feeling is that this is system related, but well anyway
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.
|
|
|
|
|
|
And the beginning of my old post was "Having a senior moment..."
thanks for the reminder
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.
|
|
|
|
|
|
Since your application has been working fine in the user space, but encounters issues when running as a service, it's possible that there could be compatibility problems between your application and the service environment. You can try running your application in different compatibility modes (e.g., Windows XP, Windows 7) to see if it runs or not.
You can also check if your application relies on any external dependencies such as libraries, frameworks, or drivers. Make sure that these dependencies are compatible with Windows Server 2012 64-bit. Outdated or incompatible dependencies can sometimes cause unexpected crashes or exceptions.
|
|
|
|
|
I'll try the different modes - good suggestion. As for the dependency question, I would think if such were the case it would not work standalone. This is a *very* simple program that acts as a network connection to simulate old hardware. Trivial UI (About...) and a socket connection.
But we'll see. I just feel a forehead slapping moment coming on 
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.
|
|
|
|
|
charlieg wrote: Trivial UI (About...) and a socket connection.
Just wanted to mention that you cannot create a process with a GUI inside of session 0 where the system services resides. All window creation will fail.
Also, if you are using the old WSAAsyncSelect/ WSAAsyncGetHostByAddr and so forth... those will all fail. Make sure you aren't using any of the old "Async" winsock functions.
|
|
|
|
|
Excellent point, but one of the issues already identified in this migration process is that session 0 has no access to the printer interfaces. So the next step was to have the service run as a specific user.
This is where I am right now. And thank you for all the notes on WSA*, I'll check for anything like that.
Interestingly, this app is the parent of another application that seems to run just fine (same socket infrastructure).
Edited: no longer sure of the above statement.
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.
modified 12-Jul-23 6:20am.
|
|
|
|
|
Yeah, this is becoming an unexpected train wreck. This code was written back in Windows Xp land and possibly earlier.
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.
|
|
|
|
|
charlieg wrote: This code was written back in Windows Xp land
If it was me I would just say it needs to keep being run as an app or it needs to be refactored. Perhaps not completely refactored but enough so you (and future developers) can have a chance at maintaining it.
I think actually I would start with the first solution - question why it needs to be run as a service.
|
|
|
|
|
Thinking along the same lines.
What's driving the need to do this is the 3rd party emulation system. Customer wants this system to fit into their new, super secure cloud system with network licenses, etc. Lots of requirements/desires that collide with each other.
The good side of things is that the Windows side of the code is minimal - it just provides a framework for the parts that actually do all the work. Refactoring is exactly what is going on.
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.
|
|
|
|
|
charlieg wrote: C000005s to death
Memory error.
Standard problem. The environment is different so the execution flow is different. It didn't show up before because you got lucky. Now it does. If you have a testing framework you can use a memory check library to debug.
Other than that you might also want to set it up for a delayed start. Or better if there are other dependent services make sure those are in the dependency list. The start up order is not deterministic unless explicit ordering is in place.
|
|
|
|
|
Yeah, I know what it means  , and clearly you are correct that the environment has changed. As I said in another comment, its sister program works fine and is nigh identical to the one misbehaving.
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.
|
|
|
|
|
Recently, I have been working with C++ includes and while examining those used in LLVM, I came across several H header files that caught my attention. I noticed that they were not templated and contained both declarations and definitions with code. To my surprise, I found that these header files were included in multiple CPP source files. Although they only define classes, I am concerned that this may result in code bloat since each source file must generate the binary for each class implementation. In my own work, I prefer to place the implementation of any non-templated class in its own CPP source file and let the linker handle it. I consider this to be essential. However, since the writers of LLVM are undoubtedly more knowledgeable, experienced, clever, and intelligent than I am, I wonder if there is something that I do not understand. Thank you.
|
|
|
|
|
Quote: I came across several H header files that caught my attention. I noticed that they were not templated and contained both declarations and definitions with code.
Do you mean member functions implemented inside the class definitions (they are inlined, so multiple inclusion is allowed)?
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
|
Richard MacCutchan wrote: There is plenty of information...
Am I misreading that? Seems like the project is focused on compilation?
Thus why would the OP ask the question in the first place?
An enterprise system will be vastly bigger than the compiler. That is going to be true for all but the very smallest of product companies. Service companies would probably always be bigger than that.
Even a system which is doing dynamic compilation as part of the business logic should still restrict that part to a very small subset of of the system, and probably a company library.
So am I just not understanding what LLVM is?
|
|
|
|
|
jschell wrote: why would the OP ask the question in the first place?
The question makes specific reference to LLVM, so I assume that is what he is concerned about. I stand ready to be corrected.
|
|
|
|
|
Roughly speaking adding two 32 bit numbers requires 32 Boolean gates.
Why do you need millions of transistors? I know there is also substraction, division, multiplying, comparison etc. Some operations probably require way more Boolean gates than the number of bits the numbers involved in the operation are made of.
Also my guess is there is a comparison based mathematical operation type selector that directs the bits to the correct area on the processor pill. Still it’s difficult to imagine where millions of transistors go.
If I think about it more I get it, this is just Alu. There is also non mathematical stuff that needs to be taken care of as well.
|
|
|
|
|
Calin Negru wrote: If I think about it more I get it, this is just Alu. There is also non mathematical stuff that needs to be taken care of as well.
Not to mention the floating point stuff, memory cache, multiple cores, and so on, and so on...
The distance between a modern day CPU and a schoolbook design is larger than the distance between a Ford T and a Formula 1 car.
Mircea
|
|
|
|
|
Indeed, and all the peripheral systems, ADC, Timers, UARTs, I2C, SPI, DMA, PWM, DAC, to name but a few.
"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
|
|
|
|
|
A large part of the silicon real estate is occupied by large/huge caches, in some chips 3 levels deep.
|
|
|
|
|
Well, a little more than 32 (unless you count a full adder as one gate? but I wouldn't). Especially if you use any type of fast adder which is often mandatory to hit frequency targets. Subtraction doesn't cost much extra, you can reuse your adder by turning it into an adder-subtractor. Comparisons don't cost extra, comparison is subtraction. Multipliers are bigger.
So it costs a few more gates than you estimated, but also there are far more transistors: billions, these days.
(Scalar) ALUs are not a big part of a modern high-performance CPU, even after accounting for there being a handful of them (I mean multiple per core, of course there are usually multiple cores too). Here's a fun article showing how big various parts of a CPU actually are, keep in mind it's showing a super obsolete Pentium 4: Intel’s Netburst: Failure is a Foundation for Success – Chips and Cheese
|
|
|
|
|
Thank you guys for sharing
> harold “fast adder”
That must be a recent improvement ( I have no clue, just a wild guess ) I’m just starting to understand what is probably the classical model.
> tronderen “real estate”
I like to think in somewhat similar terms
|
|
|
|
|
Not that recent. The 8008 used carry lookahead for example. And several 74181 (a 4-bit ALU chip which you can use multiple of in a group to build a wider ALU) could be combined with the 74182 (lookahead carry generator) to build an ALU with carry lookahead. These things are ancient (70's era tech).
That does not mean that carry lookahead addition was always used everywhere, some chips were really trying to save on transistors and didn't use it. But anything modern, probably has some sort of fast adder. Ripple carry adders do not scale well (imagine a 64-bit ripple carry adder, yikes) and transistors are significantly cheaper than a dime a dozen.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
