Win32/x86 Assembly Language Expert Needed

See detailed reqs... ## Deliverables This is essentially a port-to-assembly language project, which should be very simple for a seasoned win32 asm programmer, given that the C++ program I want you to port is already only 32K when compiled with Microsoft's CRT statically linked... To get the current C++ program files, go to the following url: [login to view URL] If for any reason the link doesn't work in your browser, just go to [login to view URL], click on windows programming and expand the article "Maintaining the Software-User Contract: Startup Delays" First of all to help you understand what the program is for, you might want to read the article (7 paragraphs)... Then download the four C++ source files at the bottom of the article: [login to view URL], DLUConv.h, [login to view URL] and stdafx.h As you will see, the program itself is very simple. There are then two parts to this job, and you can do them in whichever order suits (i.e. make the changes for (1) either before or after porting the code) Requirements: 1. Firstly, standardise the program so that instead of hard-coded strings, it accepts two command line parameters (both will need quotes), one being the fully-qualified path to the executable the program is to launch; the other being the complete text that is displayed using DrawText() in the _Draw() function in [login to view URL] - this param should be warts-and-all and a direct replacement for the current hard-coded string, i.e. it will include \r\n where appropriate. Note that your ported version must interpret both command line arguments as unicode strings which might, for instance, include the Copyright symbol and other unicode alphabet chars directly (i.e. passed on the actual command line). 2. Secondly, I need the program ported to pure win32 asm and, crucially, _without_ the C standard library and minimal use of system libraries. Also, preferably contained in a single .asm source file compilable by any free asm compiler you like. 2a. So, for one thing, in the current scenario, the wWinMain() function in [login to view URL] is actually called by the CRT's standard entry point (after the CRT does a number of other unecessary - for this program - things...) Thus, in your asm version, there is no need for any of this 'pre-winmain' stuff, so rather than a CRT winmain, your version should simply have one entry point which is an assembly language port of the C++ wWinMain in [login to view URL] 2b. It's been a while since I did any assembler programming so I'm not sure what the situation is with types, but as I'm sure you're aware, a Windows 'handle' is simply an unsigned 32 bit integer, so no need for strict type enforcing or anything. In fact, you might want to simply not bother including any windows headers at all and just use LoadLibrary() and GetProcAddress() for every OS function the program uses. Whatever, you usually do... 2c. This is also critical... the aim here is for the resulting win32 executable to be as tiny as possible. Clearly having no CRT will help with that, but there might also be other things you can do. 2c (i). For instance, you might want to do one of these two things: (..1) Remove the reliance on GetTickCount() by simply calling srand() with a hard-coded value. ...OR... (..2) What would be much better is if you could write a (small) function to generate pseudo-random numbers yourself, tailored to how rand() is used to determine progress increases. The only reason for using random increments is to make the progress bar appear as though something is being done (which is in fact the case technically - just by the .NET framework or the Window loader, not this program :) So, if you can either produce a very simple RNG that is good enough for that purpose (i.e. very simplistic one) OR use some other way of making the progress steps appear random in the same way as the compiled C++ version does, so much the better. 2c (ii) In the same vein as this, try to reduce dependence on OS functions as much as possible. If you can, by doing this, avoid the need to load one of the Windows DLLs at all, so much the better... (Basically, anything you can do to reduce the time the program takes to load/run, the executable size and any other way you can make it ultra-efficient, please do.) 3. Don't worry about the namespacing I've used for the DLUConv functions; just use elongated function names. Or, since from memory only two functions are used, and even then only once, you could simply move only the required (ported) code out of these functions and into the routine/function that is your equivalent of _Draw(). 4. Further to this, I would be quite happy if you remove function usage altogether (except for the __stdcall OS callbacks, i.e. thread proc and wndproc) and simply use conditional jumping to separate out bits of code. Again, the idea is to make the program as efficient as humanly possible, so the fewer stack pushes and pops and frame pointer instructions to facilitate function calling the better. 5. An obvious one: since the program is to be used for launching any target program, change the window class name to something other than "StartNRT". Again, a potential perf gain here in that since your class name is app-level, a simple, meaningless single char string for the class name is fine. 6. The program currently uses ShellExecuteEx() to launch the target exe. Clearly, this and similar functions reside in [login to view URL]; as suggested above, if you could avoid needing to link or load function addresses from any OS DLL completely, that is desirable. So you might want to use CraeteProcess() instead, which resides in the kernel dll. 7. Any other simplifications you can make along the same lines; for isntance there is at least one call to OffsetRect() - you can save the function call by just using the appropriate add/sub instructions. 8. Everything about the wndproc and thread proc must be identical in behaviour to the C++ version. (As must the whole program.) 9. Just for the sake of easy maintenance of the product this is currently used for, if either command line string is missing, please default it to the one from StartNRT. Ignore any additional parameters passed on teh command line, just assume the first two (after actual module name) are the two you are interested in; don't care which way around they are. 9a. Also, change the name of the executable from [login to view URL] to [login to view URL] (or anything suitable you like). 10. Any opportunities you can see to do things like combine arithmetic operations where (e.g.) you have two subtractions that both work on 32 bit values in the C++ code, but which you can establish will never > sizeof(16 bits) if you could optimise the two operations into one... or anything else like that you can think of. (Might not be realistic / be overkill in reality.) 11. Also, in terms of how your ported version is organised, if you can save space/time by including data directly in the code segment (not sure if that's sensible or not) - hopefully the actual code length will be so small that you can use only local jumps throughout. 12. MASM32 preferred, but alternatives also considered. 13. **IMPORTANT** Following on from minimal library usage: I would hope that at a minimum you only need to link to at most the kernel, GDI, and user DLLs. 13a. Note if I have used any CRT functions in the C++ version please use either a very quick custom implementation or an equivalent function from one of the three libraries mentioned in (13), e.g. use lstrlen (from kernel32) in place of wcslen(). 13b. Not sure if there's any advantage in it, but you might be able to reduce formal linking to only kernel32 (from which you can invoke LoadLibrary() and GetProcAddress() directly on the other libraries for specific functions. This might result in a slight performance advantage over allowing the linker to do it for you, it might not. I'm not an expert. And that's it. Note I am looking ideally to get the executable down to <10K, anything more than that you can squeeze so much the better. * * *This broadcast message was sent to all bidders on Tuesday Dec 13, 2011 5:28:26 PM: * * *This broadcast message was sent to all bidders on Tuesday Dec 13, 2011 5:38:47 PM: One other thing: as with the C++ version, this must run on all NT flavours of Windows from 2000-7 inclusive, although if it improves things, don't bother checking the OS version: I will only use this program where it is appropriate. Also, only deliverable for this job is your ported .asm file. Many thanks, Chris * * *This broadcast message was sent to all bidders on Tuesday Dec 13, 2011 6:07:01 PM: Apologies for the multiple addendums... Just a quick note that if you need the curent C++ executable, go to Freeware on my site and download Network Response Tester * * *This broadcast message was sent to all bidders on Wednesday Dec 14, 2011 12:21:30 PM: Many thanks. * * *This broadcast message was sent to all bidders on Friday Dec 23, 2011 10:00:03 AM: ****** * * *This broadcast message was sent to all bidders on Friday Dec 23, 2011 10:07:17 AM: Ideally, your asm code will not contain any of the set of call instructions at all, except when calling a Windows function. Everything within the program itself should be done with only conditional and non-conditional jumps.. (i.e. only the Main/WinMain function, and the two _stdcall windows calllbacks (threadproc and wndproc). For everything else, just use procedural code and 'unroll' multiple calls of the same function to a single block of code that jmps to where the function return would have been, using some kind of sentinel to indicate which instance of the function call is being dealt with... that's the kind of really low-level advantage that I'm looking for here, and any similar tricks or hacks you know,