TCLib example for Patrice

[Frederick J. Harris]

NODEFAULTLIB has already been there. Yet we need an /MT switch too because we can't avoid either /MT or /MD in the project settings.

Ahhh!  You are right.  It can't be removed in the IDE I guess.  But it is ignored if the :NODEFAULTLIB switch is in effect. 

[Mike Lobanovsky]

Regarding your .mdb failure, this seems to be quite common when you're trying to (or cannot help but) link against different C/C++ runtimes, including custom implementations thereof. The matter is each runtime (especially DLLs) uses its own memory management, so that if some remote dependency also pulls in plain msvcrt.dll somewhere, you're in a big trouble with exchanging common objects between your modules. You simply wouldn't be able to trace all of them to ensure each one of them is destroyed by its immediate parent. Same goes about the file descriptors, and pointers to them, created by different C/C++ runtimes. They aren't interchangeable/usable between the modules that are linked against them. You can google for more info on these issues, and IIRC they are also described quite clearly in MSDN.

That's why I prefer to use ANSI C whenever possible and link everything against the good ole' msvcrt.dll available everywhere as a standard system library.

[Patrice Terrier]

of course i added the "Multi-threaded (/MT)", first thing (forget to say about that one).

Mike--

I will download your updated project to use the same settings than you.

I am curious to see if this could work with some of the projects we are working together.

...

[Frederick J. Harris]

By the way, this is the link to the Petzold essay on Visual Studio.  I had the 'Brain Dead' part wrong.  His actual phraseology is 'rot the mind'...

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

[James C. Fuller]

Patrice,
  My version is not the same as Fred's. I needed to make sure there were no conflicts with my bc9Basic RTL functions. I don't think I drastically changed anything just added to it. I use WinApi file IO even though there are the normal crt functions because of conflicts. It is extremely granular.

Another thing I discovered is VS practices dead code removal. Unfortunately I found out about this after I had a major portion of José's CWindow/Afx ported using my own wrappers . I'm glad I did it my way as the c++ code is cleaner.
bc9Basic puts all the translated c/c++ code in one file. If it's not used vc does not add it to the exe.
I think? MinGW has a way to do this but I don't know how to do it.
This does not include class methods but does include the whole class and methods if in the same source but not instantiated.

James

[Patrice Terrier]

Here is my "Address" VS 2015 version.

- Only the resulting "Adress.exe" inside of the "x64\Release" folder.
- No more warning message of any kind.
- And a resulting size of 11Kb.

The Visual Studio IDE from VS2015+, is very handy to follow all the changes done in the code, and it is of great help to detect typing errors (especially for those with a huge BASIC background).

The C++ dead code removal is another great feature, that allows me to embed my common includes files, without first removing the unused functions.

...

[James C. Fuller]

Patrice,
  Labels not visible.
Built with 2015 community

James

[Patrice Terrier]

dwStyle must be moved before the CreateWindowEx.

Code Select Expand


HWND AddLabel(IN HWND hParent, IN DWORD dwStyle, IN WCHAR* sLabel, IN int x, IN int y, IN int w, IN int h, IN int nID, IN HFONT hFont) {
    if (dwStyle == 0) { dwStyle = 0x50000000; }
    HWND hCtl = CreateWindowEx(0, L"Static", sLabel, dwStyle, x, y, w, h, hParent, (HMENU) nID, GetModuleHandle(NULL), NULL);
    SendMessage(hCtl, WM_SETFONT, (WPARAM) hFont, (LPARAM) 0);
    return hCtl;
}

and i would rather use right justification instead of the left alignment.

[Mike Lobanovsky]

I needed to make sure there were no conflicts with my bc9Basic RTL functions.

No problem James, you're the boss. Besides, GNU compilers seem to be generally more permissive to type checking and most of the size_t/ssize_t warnings simply wouldn't appear in Code::Blocks and GCC or TCC. This just means both approaches can justified: either fix the sources manually to comply with VC's stricter type checking or use pragmas to suppress specific warnings the way Patrice did in his Main.cpp.

- And a resulting size of 11Kb.

You cheated!    You altered manually the control creation code auto-generated by James' Dlg2Sdk tool!

I am curious to see if this could work with some of the projects we are working together.

Why not? But I think our end-user projects would not be the proper point to start at. I think GDImage64 and WinLIFT64 should be recompiled first to ensure all the project modules and dependencies are sharing a common memory pool in this custom TCLib runtime implementation rather than conflicting with standard C++ linkage.

[James C. Fuller]

Patrice & Mike,
  I have an item in TCLib that might interest you.
I have always used Joergen Ibsen's aplib (http://ibsensoftware.com/products_aPLib.html) for my static compression needs. It's not too fast on the fly so I only use it for static data. BUT its decompression routine aP_depack_asm_fast is VERY fast. It's source is provided for FASM 64bit  and I tried to get Steve or others on the MASM forum to port it to ML64 but to no avail. I ended up installing FASM and compiling myself . Anyway the function is tcl_depack_asm_fast(const void *source, void *destination).

James

[Mike Lobanovsky]

Thanks James,

The resource is definitely worth studying! I'm doubtful as to whether I'm going to ever use it in my public projects due to its restrictive license but I will certainly both scrutinize the decompression sources and reverse engineer the library just to see how it works. The U.S. law allows me to do that because it's free software and thus I'm a legal owner of my copy of all these modules.

[James C. Fuller]

Mike,
  Like I said  I've never USED aPLib in a product so I see no restrictions. I used it to compress data, and then used the compressed data in a project. I don't read any restrictions into using the decompression code??

James

[Mike Lobanovsky]

No no,

Decompression is open source, and you can use and/or modify it as you see fit as long as you keep Ibsen's original blurb intact. But the compression library part is closed source and you may not sell it. If it is used as a dependency that some feature of your TCLib relies on, and the bc9 output source that's free for any use, including commercial, might incidentally inherit this dependency through the use of that TCLib feature, then the library's license and the end product's commercial usage would clash.

Yet being a legitimate owner of the library, I am still entitled by the supreme U.S. laws that have priority over common trade licensing to reverse engineer (a.k.a. take apart) an instance of any commodity in my lawful possession to see what's inside it and how it works for personal educational purposes and also for making sure my own produce communicates and interfaces well with the said commodity if needed, as long as I am not making public my immediate findings nor am I making available the tools I used for taking the said commodity apart (a.k.a. reverse engineering it).

Moreover, based on my newly educated knowledge I am entitled to close the book (a.k.a. delete the listings I reverse engineered) and tell the poem by heart (a.k.a. create completely new source code based on what I memorized and understood from the reverse-engineered listings) in any language I please. In which case I am also entitled to distribute my own, new sources in any manner I choose: keep them closed or make them public domain, sell them or give them away for free. The U.S. legalese calls this "clean-room reimplementation". That's how ReactOS reimplementation of Win XP/2003 has been taking place in the recent 15 years or so.