I have a program that will convert Platform SDK headers into Asm include files. I have given the ability to convert to TASM and MASM. I would like some feedback from other people. I will try to post my exe at some time on Iczelions site. For the moment I need to ask a couple of questions: 1. Does anyone think this will be of use? 2. I Have got it to the point where I actually parse the IF statements and could do evaluations during conversion. Should I? I have a checkbox for enabling/disabling processing based on the IF's. Should I keep this? 3. Would anybody be interested in helping get rid of the few minor annoyances I have left, that stop complete conversion. (Example: RICHEDIT.H -> RICHEDIT.INC there is probably 3-5 minutes of cosmetic changes to finish.) ? 4. Would there be any interest in conversion to NASM format? 5. How about SpAsm? (What do you say Rene). 6. Should I keep with all the different TYPEDEF's or just try to reduce down to a certain few TYPEDEF's? The program will also parse nested include files. Let me hear from the group that would benefit most.
I think you may have competition! Doesn't h2inc.exe already do this? One thing that might be useful is a utility to produce inc files directly from dll's. The problem is getting the prototypes. I have done this using IDA -- IDA emulates actual execution, hence infers the prototypes of the various functions on a "run-time" basis (arg_4, arg_8, etc., appear in the asm listing). It doesn't always get this right, but running the IDA output through a home-brewed C-language program (or even Perl script) and then cleaning up the relatively few mistakes is a lot easier than doing everything by hand. Another thought might be to use dumpPE on the dll and strip out everything but the publics. Here you can deduce the prototypes from the decorated names (assuming the dll is a C++ dll, this won't work for straight C). Good luck with your project. Alan
First off, I use MASM(32) exclusively, and limit my comments to that enviroment. h2inc is TERRIBLE. I for one would love a replacement that could handle the C include files without extensive modification. Actually parsing the conditionals is a real necesity, either to generate includes for one or another condition (in seperate files) or to translate the conditional compilation statements into further MASM style conditional statements. Mis-handleing conditionals is the real bug in h2inc. I'd also go for MASM32 style 'loose' type checking. I get along with this just fine, and if us ASM guys don't know that a pointer and a handle are both dwords, we're dead anyway. I followed this convention myself when I wrote the CoLib component object library. Summary: I WANT IT!
1. Yep, it'd be VERY useful! 4. Yeah, give it the ability to convert to NASM :-) ------------------------------------ Team2k PC Development Team: http://ppilot.homepage.com
1. Certainly I need this(and not only me). 2.h2inc is too "static" to configurate it it for real (Win32)asm needs. (E.c., You could define more or less same defines as with C compiler (cl) - /DWIN32 /DUNICODE /DI586 (?) and so on. ) But that would be nice if it is selected in the interface. (Also, it would be nice to have an ability to switch between MASM/TASM (NASM) - style .inc to produce. (radio-buttons?). Though I'd probably keep the first one (MASM) selected all the time. ;-) Summary: Depending on /D..... passed to Your prog (or smth. like that /D par. in h2inc) it would produce different .INCs - according to #ifdefs in .h But maybe, to reduce the size of the resulting .inc, You'll have to keep that checkbox for enabling/disabling parsing IFs. 3. That'd be intersing for me. 4.Probably, if You'll have some time. ;-) (Check my op. on this in p.1) Anyway, v.1 could be released without NASM feature, i think. ;-) (We can add it later) 6.Probably keep all TYPEDEFs - Some messages or structs, e.c. are different for UNICODE or MAC. Better implementing it in smth like this (way): ;========= result.inc========== WM_SOOPAMSGW EQU 123 WM_SOOPAMSGA EQU 124 SOOPASTRUCTW STRUCT ... SOOPASTRUCTW ENDS LPSOOPASTRUCTW TYPEDEF PTR SOOPASTRUCTW SOOPASTRUCTA STRUCT ... SOOPASTRUCTA ENDS LPSOOPASTRUCTA TYPEDEF PTR SOOPASTRUCTA IFDEF UNICODE ;then no /DUNICODE is needed ,however) WM_SOOPAMSG EQU WM_SOOPAMSGW LPSOOPASTRUCT EQU LPSOOPASTRUCTW ELSE WM_SOOPAMSG EQU WM_SOOPAMSGA LPSOOPASTRUCT EQU LPSOOPASTRUCTA ENDIF This way I could perform easily in my ASM source: -Just define a variable for MASM preprocessor. ======= .386 .MODEL FLAT,... UNICODE = 0 .... ======= Personally,I 'd like it this way. Good LUCK with Your project and I want to hear smth. from You soon!