Patrice,
I doubt very much you can live without STL :) but here is a C++/TCLib example using my version of Fred's TCLib (included).
You cannot use the Visual Studio IDE. All compiling is done from the command line using the included batch file.
TCLib.lib kernel32.lib user32.lib are the libraries linked by default from the batch file.
Give it a go!
James
Quote from: James C. Fuller on January 12, 2017, 02:10:08 PMYou cannot use the Visual Studio IDE.
But why not? Actually you can! ;D
Below is a VS20
13 Ultimate solution for TCLib and ForPatrice01.CPP. A similar one can be used in VS20
15 too; just change the C++ toolset in the project General Configuration properties from
v120 to
v140 and add the compiler
/Zc:sizedDealloc- option unavailable in VS2013.
The project compiles with warnings (Strings.h/.cpp seem to redefine a lot of VC common stuff and they also use "deprecated" functions)
but without errors. The resultant executable (get it in the \VS2013\x64\Release subfolder) is exactly as large and functional as the one generated with your batch file.
Mike,
Thank you. That's what I get for supposin'.
No use to me as I don't use the ide but might get Patrice started.
James
Patrice couldn't understand this type of dialog code :-X
Couldn't get it to work on 2015, nor with my VS Pro 2013.
...
Patrice,
I was able to create a VS2015 community version.
I created a VS2015 folder in the JCFULLER folder and copied the files from the VS2013 folder to it.
I right clicked on the JCF.sIn and opened it. It updated to VS2015 and I was able to build the solution.
Now I am curious, and would like to know how to create a new solution from scratch preferably the sdk version not the rc versiom. Mike?
James
@James:No problem. Below is the ForPatrice02 solution with the SDK version of the file. It is exactly the same as the RC version except:
- its JCF project refers to the 02 versions of source and resource files; and
- it references two more LIBs in its link stage: gdi32.lib and comctl32.lib.
Creating a solution from scratch is pretty straight forward:
- create an empty C++ solution;
- add the existing CPP file(s) to the Solution Explorer's Source Files section;
- add the existing RC file to the Solution Explorer's Resource Files section;
- if you aren't planning to edit the header files and they are appropriately #include'd in your CPP file(s), then you may omit adding them to the Header Files section of Solution Explorer; and
- if your resources (like e.g. the manifest file) are appropriately referenced in your RC file and you aren't going to edit them, then you may omit adding them to your solution.
Then just open up your batch file, select your project in the Solution Explorer, goto your PROJECT->Properties->Property Pages dialog from your main menu, and looking in your batch file's compile and link options, try to find the matching entries and settings in the Property Pages dialog's Configuration Properties->C/C++ and ->Linker options. Note however that the Property Pages options are not 100% exhaustive and there are always some compiler/linker options that you will have to add manually to the appropriate <edit...> fields in the respective entries. E.g. while you can set the /STACK: reserve[,commit] option directly in the linker settings, to the best of my knowledge there's no option for the /GsNNNN stack size parameter, which you will have to add as an extra in the Additional Options entry.
Make sure to click the Apply button if you've just changed some setting or option
before you proceed to another page in the Property Pages dialog! If you don't do that then your changes will not be reflected in real time in the All Options and Command Line summaries of respective C/C++ and Linker sections of this dialog.
(James, this isn't a .SIN file, it's a .SLN file - as in "solution", not "sin"... ;D )@Patrice:I don't know what your problem might be in either one of your Visual Studios. It's a valid VS2013 solution without any Ultimate or Professional specific dependencies so it should also be usable even in the VS2013 Community mode. And if you try to open it in VS2015, then the first thing Visual Studio is gonna do will be asking you to upgrade it to the VS2015 format, which in fact will boil down to promoting its declared toolchain from v120 to v140...
[UPD] The zip below has been updated with cleaner, more precise solution project settings (see my Replies #7 and #9 below). Please re-download.
This one works, and creates a 13kb exe binary. :)
Great! This is exactly how large (or in fact small) James' original executable is when generated with his batch file.
As an afterthought (a.k.a. "did you know..." a.k.a. "tip of the day"):
- you will probably be able to avoid the compile-time "deprecated" function warnings if you add the following extra macro to your Property Pages->C/C++->Preprocessor Definitions: _CRT_SECURE_NO_WARNINGS;
- even if you aren't (accustomed to) using VS solutions to compile your C++ projects, you may still find it useful to i) create a dummy solution for your project; ii) add its files to the appropriate sections in the Solution Explorer; and iii) add your existing .BAT file as a TOOLS->External Tools... facility in your VS main menu. In this way you will be able to enjoy VS' automatic highlighting, formating, and intellisense facilities for editing your source files while preserving total control over the build process via your own generic batch file. Just be sure to avoid the BUILD menu and instead, use your proprietary External Tool to create your project with. :)
I have already removed all the warnings 8)
Or just add this at the top of the main section
#define _CRT_SECURE_NO_WARNINGS
and in the
Preprocessor Definitions _UNICODE;UNICODE;%(PreprocessorDefinitions)
to get rid of the WINVER_WIN32_WINNT_VISTA invalid macro definition.
and use (long) or (int) in front of all _tsize that are affected to int.
and
bool String::blnSuccess() {
BOOL bRet = FALSE;
if (this->blnSucceeded) { bRet = TRUE; }
return bRet;
}
Quote from: Patrice Terrier on January 13, 2017, 11:10:46 PMI have already removed all the warnings 8)
That's cool, Patrice!
However:
- We agreed to create a valid solution, didn't we? We could define all preprocessing directly in the main CPP file through macros and pragmas but we should set the solution environmental options properly instead.
- With a view to Item 1, _CRT_SECURE_NO_WARNINGS is all right but it should be moved out of the CPP file and into Preprocessor Definitions _UNICODE;UNICODE;%(PreprocessorDefinitions).
- WINVER=_WIN32_WINNT_VISTA and _WIN32_WINNT=_WIN32_WINNT_VISTA should be left in their places with equal signs added (I did overlook them when copy-pasting though). After all, they were defined by the original author and these environmental variables may probably be still meaningful for proper linking against the library.
- C/C++->Code Generation->Runtime Library should be set to Multi-threaded (/MT) static library compilation. This will remove the DLL warnings.
- You shouldn't enforce your casts where the author has not yet had their say. Probably James or Frederick would first explain why their own parameter definitions were so lax as compared to what's expected in VC? In the meantime, the executable will perform as expected even while the remaining few warnings are still outstanding at compile time.
- I've replaced my original JCF4PT_02 submission with the new one where the above faults have been fixed. You can re-download it from my Reply #5 above.
There never really has been much doubt in my mind that TCLib could be utilized within Visual Studio. Just not by me. I'm the kind of person that's willing to put just about any amount of work into solving an intriguing programming problem if I think there's any chance at all of solving it, but when it comes to fighting IDEs, I just don't have much patience. The sorts of things I had to do to achieve the kinds of radical size reductions I wanted are kind of unusual in the extreme, and I always knew VStudio would fight tooth and nail 'agin it. And it takes all of about one minute to create a folder, paste a few files in it, open a command prompt window to it, and execute a command line string or batch file. And one doesn't end up with piles of crazy directories full of crazy files.
There are more sinister aspects to all of this too, which I'm only just beginning to realize. I don't know if its still there, but years and years ago Petzold put on his site an essay something to the effect "Does Visual Studio Make You Go Brain Dead" or something like that. He picked up on it before anybody.
Occasionally I've posted code in various C or C++ Forums which folks can't get to work because of the file redirection that goes on when executing through the Visual Studio IDE, what with all the folders and subfolders it creates. Of course, there are all kinds of setting within the IDE where these kinds of things can be modified, if a body wants to take the time and expend the aggravation to figure it out. If expending an hour of your time to save yourself one minute is your cup of tea.
Using the IDEs for coding and project organization is fine for me. I particularly like Notepad++ and CodeBlocks. I'm sure there are other good ones too. I had to give up on Visual Studio as an editor because I code on batteries a lot with my laptops, and Visual Studio eats through a battery in no time. At least that's my experience. Just my opinion.
Hi Frederick,
James and I initiated all this to get Patrice attracted to the project. Otherwise he wouldn't use TCLib for the life of him, without a decent VS solution appended. :)
There's another one of those thingies like CRT_SECURE_NO_WARNINGS something to the effect NONCONFORMING_SWPRINTF I occasionally need to use.
About the /MT thing. It really has no place in the command line compilation string if linkage with TCLib is the goal, as its effect is to tell the build system that static linking with the C Runtime libraries is the goal, which is quite antithetical to the use of TCLib, whose goal is to eliminate the C Runtime. However, it seems OK to keep it there as within TCLib itself there is a :NOEFAULTLIB switch which seems to cause the build system to then ignore the /MT switch.
No Frederick,
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. VS does have its own glitches but still it has its benefits too. (I'm personally more used to Code::Blocks and GCC too but having the honor of working with Patrice on a few common projects, I've been getting used to Visual Studio as well even if somewhat reluctantly, I must admit. :) )
Quote
James and I initiated all this to get Patrice attracted to the project. Otherwise he wouldn't use TCLib for the life of him, without a decent VS solution appended.
I was wondering why I hadn't heard anything from Patrice about his success or failure with TCLib. I always felt it would help him achieve some size reductions with his code. I don't personally do any heavy duty graphics coding like Patrice is famous for, but my limited understanding of it is that such usages rely exclusively on Windows Api code. And I suppose some graphics libraries involving Direct X and so forth. If those other libraries require loading the C or C++ runtimes then it might not work. Only recently (last week) I came upon my first encounter with something I couldn't get TCLib to work with. It was SQLConfigDataSource(), which is in odbccp32.lib, which is the ODBC Installer library. I occasionally make use of that function to create Microsoft Access *.mdb files on the fly. Try as I might I couldn't get it to work. Don't know why. That's one I did give up on.
But when I realized from reading here that Visual Studio was the culpret, I was about to go searching for Patrice's C++ rendition of the Address sample all of us were playing with a couple years ago in investigating PowerBASIC DDT verses SDK code. I always wanted to test that with TCLib, but just haven't been able to find the time. My guess is that could be done in 22 k or so x64.
Quote
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.
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.
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.
...
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
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
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.
...
Patrice,
Labels not visible.
Built with 2015 community
James
dwStyle must be moved before the CreateWindowEx.
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.
Quote from: JamesI 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.
Quote from: Patrice- And a resulting size of 11Kb.
You cheated! ;) You altered manually the control creation code
auto-generated by James' Dlg2Sdk tool! ;D
Quote from: PatriceI 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.
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
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. :)
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
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. :)