Maximilien wrote:

kamarlonaire wrote: FOR STREAMIN OF VIDEO ON TO THE CONSOLE you want to stream video to a text console ????

This has been done before[^] Sad, but true.

Well, of course. Debug builds include everything (even unused code). In order to see what I'm talking about, it has to be a Release build with program database generation (/Zi, adds about 32 extra bytes to the final EXE but necessary for various things) and you need to be using a static code disassembler (e.g. IDA Pro). In other words, you need to set up your dev. environment so you can reverse-engineer the EXE (binary file) to see what I'm talking about. BTW, I compiled the simplest EXE possible (console program, displays "Hello") in Release mode and it generates a 160K file with the library, a 56K file without. It should be about 60K. There is 100K of unnecessary code being included.

I'm "damn sure". And don't "guess" - know. And I can't make it a DLL (if I did, the DLL and the EXE would both be huge, which is the opposite of my main goal). It is a static library linked against the final EXE as demonstrated by my original post. Only people who have experienced the problem I've got should be replying - really large libraries used across multiple solutions and projects that are including 'static' functions that are never referenced. You apparently don't fall into that category. Also, I just discovered a set of static functions in the final EXE that are in a class that is completely unrelated to the program itself (NT Service related functions - and the program is not a NT Service nor makes any calls into the class that has those support functions).

Huh? Notice the .lib and .exe split of the original post. The .lib file IS a static library linked against the final .exe.

What I want to achieve is a smaller executable. And my point is that static functions I'm not referencing ANYWHERE are being included in the final executable for no good reason other than they have the 'static' keyword. I've noticed that not all functions are being included - some are getting optimized away - but not all of them.

Let's say I have the following: ---- Start .lib ---- class A { ... }; class B { public: B(); int Func3(); static int Func1(); static int Func2(); }; class C { public: static int Func1(); }; ---- End .lib ---- ---- Start .exe ---- ... int main() { C::Func1(); } ---- End .exe ---- This is the simplest example of the problem. C::Func1() calls B::Func1(). B::Func1() executes code but DOES NOT instantiate class A, call B::Func2(), or instantiate any instance of B(). B::Func2() instantiates an instance of A and B. I have all Visual Studio 2008 compiler optimizations turned on that I can find (/GL, /Ox, /GF, /OPT:REF, /OPT:ICF, /ltcg). Yet, when using a static disassembler, I can clearly see that just because I reference one static function in a class (B::Func1()), even though the other static functions in the class are not used (B::Func2()), that code is included, which in turn makes any classes they use get included (e.g. class A), and then those functions include classes they use.... The end result is an unnecessarily _huge_ executable. As I said, this is just a simple example. As far as I can tell, this is a "bug" that has been in VS since VS.NET. The only thing I can think of to possibly solve this is to create a class for each and every static function in the code...but that will likely take weeks to complete. Any better suggestions other than that? And it would be really nice if anyone here could confirm that this is actually a bug in VS.

modified on Saturday, March 15, 2008 12:41 PM

From my original message, "despite specifically generating a unique name for the .pdb file for the third-party .lib, I still get LNK4204 warnings" If it were that simple I wouldn't be asking.

"... is missing debugging information for referencing module; linking object as if no debug info." Here's what I'm doing: 1) I have a third-party library that I am building as a separate solution. It generates .lib and .pdb files. 2) I have a library that I've written that I use in all my solutions. So, logically, I should be able to take the third-party .lib and .pdb files and add the .lib to my .lib's dependency chain (Properties->Librarian->General->Additional Dependencies) and build and everything should be okay. But it isn't. For whatever reason, despite specifically generating a unique name for the .pdb file for the third-party .lib, I still get LNK4204 warnings. Is there a way to get the linker or librarian to include the contents of another .pdb file into another executable/library .pdb file?

Look at "FSCTL_LOCK_VOLUME". MSDN Library has this to say about it: "The system flushes all cached data to the volume before locking it. For example, any data held in a lazy-write cache is written to the volume."

VC8 is Visual Studio 2005 (not what I have). VC9 is Visual Studio 2008 (what I have). And MFC has some weird stuff involving language separated DLLs (MFC directory AND a MFCLOC directory). What do I do for those? How do I get my old VC++ 2003 projects to start using side-by-side? Right now the compiler is looking for the 7.1 version of the runtimes (msvcr71.lib), not finding it, and therefore the linker is failing. Remember, these are imported solutions and projects from VC++ 2003.

I recently discovered that Visual Studio 2008 puts its runtime libraries in the side-by-side assemblies directory. A lot of my projects have dependencies on the runtime DLLs. According to what I've read about side-by-side, it "requires" the use of Windows Installer to deploy them. However, I've invested significant time in learning and using Inno Setup and don't really like the Windows Installer for various reasons (some personal, some professional). I guess my question is: How does redistribution of side-by-side assemblies work (behind the scenes)? I should point out that my projects are being imported from older versions of VS and I'm wanting to fully update them to the latest version of VS. Side-by-side is new to me.

I've done that before. IIRC, you have to delve into DeviceIoControl().

And, no thanks to anyone here, I found an existing tool that comes with XP out-of-the-box that looks like it will do the job nicely after modifying the registry a bit: 'netsh' (subcategories: 'routing ip nat' and 'add addressmapping').

I'm knowledgeable enough to know how to use Detours to do what I want. Just wanted to know if there was already software to do the job. And a commercial firewall/NAT will do the trick too as I already pointed out. And Linux will do it as well. Just wondered if something was available for Windows before I rolled my own. Gee wiz. People are paranoid.

For Windows XP? Anyone know of some sort of software-based tool (preferably free) that I can set up a rule that will redirect all requests to a specific IP address (outside the LAN) and port to a different address (inside the LAN) and port AND when packets come back, they look like they came from the original target? (It has to work on a Windows XP box. And don't say Linux.) I only need this for a temporary setup for about an hour or two. It can't be hard to do - I mean, I occasionally (= rarely) run Ethereal to sniff packets and botnet software can spoof the source. I know a full blown commercial NAT firewall/router will do the trick but, as I said, this is temporary and I'd rather not spend money. Edit: The part about the botnet probably sounds wrong. I meant to split that into two sentences: "I occasionally run Ethereal to sniff packets." "And [I know] botnet software can spoof the source." -- modified at 20:33 Thursday 6th September, 2007

Muammar© wrote:

fffffffffffffffffffffffffffffffffrrrrrrrrrrrrrrttttttttttttttttttttttttt333333333333

Fartie!

I forgot to mention that I'd like to remain as cross-platform portable as possible (Preference: BSD-style socket calls) and also something that works under NT 4 (Win9x support would be nice but not necessary) and the language I'm using is C++. The IsDestinationReachable() API is not useful. It just returns the line speed of my Ethernet connection (100Mbps).

I've seen various applications that run on Windows detect the upload speed of data being transfered upstream. Obviously this can be done through some feature in Winsock that I can't seem to find. I can do a send() on a non-blocking socket of 1MB of data and it returns immediately and successfully but I know the data is just queued and being sent at about 40K/sec. How? What API? Actually, never mind. I'm pretty sure I've figured it out. -- modified at 3:20 Monday 3rd September, 2007

Thanks. I'll just assume it works fine in VS 2008 as well.

I don't have Orcas installed and really don't want to risk messing up my main build environment, which is a pretty delicate setup. Dropping a new compiler on the system is the general equivalent of a tactical nuclear warhead. I want to know if the bug is in Orcas (i.e. emits an incorrect error message). Please, just run it through Orcas and post the output.