Alzri

Updates: - Implemented more functions. - Many enhancements to the library.

In short, support unicode. But, to understand fully how it works, you should read the whole story; here are names of some good topics (google them): "The Complete Guide to C++ Strings, Part I", "The Complete Guide to C++ Strings, Part II", "What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)", and "WinAPI: Being Unicode Friendly". You also shall read about modernizing the code since using "new" and "delete" is nasty: "Using STL Strings at Win32 API Boundaries" Thx for the info. Let's forget about converting and focus on the library cuz writing a converter is just a matter of trial and error process (with having the right approaches ofc). But for this particular subject, there is a way by finding the first assigning for the variable... the converter can take these steps: 1) find when a variable is declared. 2) find when the variable is assigned to a value (it might get the value from the return of a function so all prototypes must be loaded first to get their return value types). 3) get the type of that value. 4) If an assignment changes the type, this means we need a new variable with a new type.

Good work @gil900 ! I'll check it later when I finish my exams... I had a glance at the code, here are my comments (they might not be accurate): 1) I think it's better to use the type wstring instead of an array char. 2) Since it's a big project, I think it's better to put all of AutoIt constants in separate files (I think using Enumeration here is a good idea). 3) We also shall focus on the main functions... how about this order: (files, environment, registry, process, network, string, window, mouse, GUI) ? 4) You may use passing values by reference (with the keyword const) instead of passing by value (to avoid unnecessary copies). Yep, that's gonna be painful to handle Surely, there are solutions; I guess using vectors is one them.

Updates (link in the first post): -Updated project to VS2015 (with upd 1) -Added "const" when passing refs -Changed into vectors containers -Fixed some bugs -Added to-do list I'd be thankful if you inform me about any unexpected behavior from any function.

Use Winrar self extractor... AES-256 is still powerful

I guess JohnOne clarified things... thanks I have not anything useful to say, just that there have been many updates since the first post (check first link). Updating pace is slow these days cuz having Physics 2 and Calculus 2 in one's life and finding time to write neat code is really hard.

For real, most of the tools suck when you try to make a neat large chm file ! When I compiled my own MSDN chm file (after extracting from HXS), I used these apps, don't remember which one worked for me: ABC Amber CHM Merger CHMaggregator ExtraCHM Far HTML v5 (I guess it's this one) HelpNDoc HTML Help Workshop KeyTools (from keyworks) PrecisionHelper WinCHM.5.01

I saw the source without testing... it's really good. For the moment, I'm only concerned with writing functions that work like AutoIt without inflict the performance. Look at this one: https://github.com/Z-Rantom/AU4-Library/blob/master/AU4Lib/files.cpp I've added this condition to au_FileFindNextFile function cuz the first file name should be returned from FindFirstFile in Windows API: if (retValues.hFileName != L"") which makes it run another test without the need of it (performance issue) except to make it behave like AutoIt

What do you mean by "it" ? If "it" is the idea then it is simple, it works... it just needs lots of work an time

I tried to find a similar project before with no luck ! Well, looks like someone has done a wonderful job. Now, I'm really considering whether to abandon the project Or better, I might copy and improve/optimize his code.

OK... this is the very first step: writing AutoIt functions in a C++ library. Another project is to write a tool (in any lang, even AutoIt) works as follow: 1) The user input an au3 file. 2) The tool (converter) starts to convert the AutoIt script: (AutoIt syntax to C++ syntax) and (AutoIt functions to correspondence C++ functions in this library). we will end up with a main.cpp (our script in a new form) with some header files and cpp files (the library). 3) C++ compiler does its job to the converted script 4) Voila ! AutoIt script output file is not "scripty" anymore, it runs like a native app.

huh ! You shall consider your measure of seriousness ! A "converter" that can replace the current compiler. The whole project is currently written in C++. In case you want to create the converter in another language, such as C#, you can do that as well. But, I'm writing the AutoIt correspondence functions in C++ only.

I've already answered that question. But, I'll explain it differently: We know that AutoIt is already written in C++, but an AutoIt app is slower than a C++ app. Why ? Because the output file of AutoIt has all the functions inside it even if only one of them is used ! Then, it reads the script from the overlay and execute it. How about C++ ? It's totally different, things are organized and faster because the compiler only includes the functions you need and writes native code. To know what I'm talking about, read this: http://delphiblog.twodesk.com/making-slow-code-go-faster-measuring-speed So, this whole project is the first step to write an Au3 to Cpp converter, you can call it: "Au3++ compiler". (thanks for jpm for the name) Yeah, let me know if you have any better idea(s) My fav color. Strange, I've searched using google and didn't get a hit ! Anyway, I've sent Jon another message about this account as well.

First of all, Thanks for that Jos... that's what we need guys, instead of using our potential and time on "why and when and where" It would be very naive to start a project without having any idea about it ! As a developer, I wanna hear others ideas to see if I can develop mine as well. Well, for the moment, it's gonna be a function-based project, no objects, no complications... and, I don't know for how much this line would hold. Also, I'm only gonna implement the functions under "Function Reference" in the AutoIt help file... AFIK, other UDF functions are just a combination of those functions. ============== Now, let's start the investigation session: As indicated in the github link in the greetings, I'm one of AT4RE members... forum: http://www.at4re.com/f/ No, there isn't. Actually, I was stunned when I read that nickname cuz that's mine, and I don't remember that I have registered before in this forum using this one. If this account exists, would you show us ? I registered in this forum before using another nickname. When I was gonna post this project, didn't like the nickname (was created 7 or 9 years ago, you can tell how awful it could be)... so I created this account, right after that, sent a PM to an admin "Jon", whom I checked has visited the forum recently, to delete the previous account. Deleting / ignoring that account is up to him as I don't intend to use it. I don't even know that this forum has a chatbox... well, I checked it and didn't find anything. Did I say that ? if not, I guess you jumped to that conclusion It's just that if someone wants to join he's welcome to do so. Told ya, you don't have to jump to conclusions... I hope that you know that mods can't know everything if someone knows what he's doing. Anyway, I don't intend to do that either in case you want to jump to that conclusion as well. In this case, there isn't a "that". ============== All that being said, thanks for the welcome guys Back to the topic, do you have any ideas ? notes ? whatever ?

AU3++ sounds nice ! Instead of focusing on the name, let's focus on the content... does anyone have ideas/ways to make it behave like AutoIt without having the original source code / reverse engineer it ? Everyday, I'm discovering something new... "not everything is as it seems"