News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

HTML to RTF

Started by guga, June 08, 2013, 01:56:26 PM

Previous topic - Next topic

guga

I have between 16 and18 converters here, and i´m testing them one by one, to make all of this work.

Btw, don´t trust too much on the documentation. It is utterly outdated and have lots of things missing or wrong there.

To know which extension can be exported you need to use the Getread/Getwrite functions. I was using before a check for RTFtoForeign/ForeitgntoRTF, but it proovesme to be not the way to go, since some converters although have this functions as exports,they simply do nothing.

Also, GetRead/GetWrite wil not work all the time, if the dll is not registered properly, this is why i believe that when it return 1 on GetReadNamesit means that the converter is not registered.

I used one routine to fecth the error messages(there is a fecth exportfor that), in conjunction with pre-defined error messages (similar to the source you provided).

I´m tired right now to test, but will take a look later.

All of the 16/18 converters will work eventually, but i need to fully understand what a hell M$ made on them, specially to avoid that some converters shows stack problems when other don´t.

Also, many of them uses msconv97.dll, and the converters (some of them) are some sort of wrapper to it.

One thing that seems valid to analyse is the return valeus from RegisterApp. The structure REGAPPRET contains information that can be modified at runtime to better configure the converter


Below is my function to check forth error


Proc GetErrorMessage::
    Arguments @ErrValue
    Structure @BufferName &MAX_PATH, @BufferStartDis 0
    Uses edx, ecx, esi, edi, ebx

    mov eax D@ErrValue
    movzx eax ax
    ..If D$CConverter.m_CchFetchLpszError <> 0
        call ZeroMemory D@BufferName, &MAX_PATH
        call D$CConverter.m_CchFetchLpszError D@ErrValue, D@BufferName, &MAX_PATH
        mov eax D@BufferName
    ..Else
        If eax = 0
            mov eax {B$ "IsFormatCorrect32 did not recognize the input file.", 0}
        Else_If eax = 1
            mov eax {B$ "The converter seems to not be registered. Please update it or register", 0}
        Else_If eax = 0-1
            mov eax {B$ "IsFormatCorrect32 or ForeignToRtf32 was unable to open the input file.", 0}
        Else_If eax = 0-2
            mov eax {B$ "There was an error reading from a file.", 0}
        Else_If eax = 0-4
            mov eax {B$ "There was an error writing to a file.", 0}
        Else_If eax = 0-5
            mov eax {B$ "There was invalid data in a document being imported through ForeignToRtf32.", 0}
        Else_If eax = 0-8
            mov eax {B$ "The converter was unable to allocate memory for this operation.", 0}
        Else_If eax = 0-12
            mov eax {B$ "RtfToForeign32 was unable to create its output file.", 0}
        Else_If eax = 0-13
            mov eax {B$ "The user cancelled the conversion operation", 0}
        Else_If eax = 0-14
            mov eax {B$ "ForeignToRtf32 did not recognize the input file while attempting to convert it.", 0}
        Else
            mov eax {B$ "Unknown Error", 0}
        End_If
    ..End_If

EndP


I´m using CchFetchLpszError to check the correlation between the error messages from the different converters. For example return 1 shows one type of message on one converter, but the same value returns no string on another (but, both values are the same error). So, this function is temporary. I´ll probably remove the check for CchFetchLpszError is all values are exactly the same meaning for all converters
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

testing the check for imports and exports is made here


Proc CheckForImportExport:
    Arguments @pDocType
    Local @GetReadNames, @GetWriteNames, @InitConverter, @UnitConverter, @hClass, @hDesc, @hExt, @pBuff
    Structure @BufferName 1024, @BufferStartDis 0
    Uses ebx, ecx, edx,esi, edi, eax

    ;move D@pConverterPath D$esi+DocType.pszPathDis
    mov esi D@pDocType
    call ConverterGetLibrary D$esi+DocType.pszPathDis;D@pConverterPath
    ...If eax = &TRUE
        call 'KERNEL32.GetProcAddress' D$CConverter.m_hLibCnv, {B$ "InitConverter32", 0} | mov D@InitConverter eax
        call 'KERNEL32.GetProcAddress' D$CConverter.m_hLibCnv, {B$ "CchFetchLpszError", 0} | mov D$CConverter.m_CchFetchLpszError eax
        call GetModuleName
        call D@InitConverter &NULL, eax

        call 'KERNEL32.GetProcAddress' D$CConverter.m_hLibCnv, {B$ "GetReadNames", 0} | mov D$CConverter.m_GetReadNames eax
        ..If eax <> &FALSE
            call VMemAlloc D@BufferName, 1024 | mov D@pBuff eax
            call GetReadNames &NULL, &NULL, D@BufferName
            mov ebx D@BufferName
            .If eax <> &FCENOERR;&TRUE
                mov edx D$esi+DocType.pszPathDis
                call ShowError eax
            .Else_If B$ebx <> 0 ; <---- why here is showing 0FF as the 1st byte ????????????
                mov eax D$esi+DocType.pszPathDis;eax
                mov D$esi+DocType.bReadDis &TRUE
            .Else
                mov eax D$esi+DocType.pszPathDis;D@pConverterPath
                mov D$esi+DocType.bReadDis &FALSE
            .End_If
        ..Else
            mov eax D$esi+DocType.pszPathDis;D@pConverterPath
        ..End_If

        call 'KERNEL32.GetProcAddress' D$CConverter.m_hLibCnv, {B$ "GetWriteNames", 0} | mov D@GetWriteNames eax

        call 'KERNEL32.GetProcAddress' D$CConverter.m_hLibCnv, {B$ "UninitConverter", 0} | mov D@UnitConverter eax
        call eax
        call VMemFree D@pBuff
    ...End_if

    call 'KERNEL32.FreeLibrary' D$CConverter.m_hLibCnv

EndP



Proc GetReadNames::
    Arguments @pOutName, @pOutDesc, @pOutExt
    Local @hClass, @hDesc, @hExt, @pMem
    Uses ebx, ecx, edx

    call 'KERNEL32.GlobalAlloc' &GHND, 1024 | mov D@hClass eax
    call 'KERNEL32.GlobalAlloc' &GHND, 1024 | mov D@hDesc eax
    call 'KERNEL32.GlobalAlloc' &GHND, 1024 | mov D@hExt eax
    call D$CConverter.m_GetReadNames D@hClass, D@hDesc, D@hExt
    movzx eax ax
    .If eax = &FCENOERR
        If D@pOutName <> &NULL
            call 'kernel32.GlobalLock' D@hClass
            call StrCpy eax, D@pOutName
            call 'kernel32.GlobalUnlock' D@hClass
        End_If

        If D@pOutDesc <> &NULL
            call 'kernel32.GlobalLock' D@hDesc
            call StrCpy eax, D@pOutDesc
            call 'kernel32.GlobalUnlock' D@hDesc
        End_If

        If D@pOutExt <> &NULL
            call 'kernel32.GlobalLock' D@hExt
            call StrCpy eax, D@pOutExt
            call 'kernel32.GlobalUnlock' D@hExt
        End_If
        mov ebx &FCENOERR;&TRUE
    .Else
        mov ebx eax
    .End_If

    call 'kernel32.GlobalFree' D@hClass
    call 'kernel32.GlobalFree' D@hDesc
    call 'kernel32.GlobalFree' D@hExt

    mov eax ebx

EndP



Proc ShowError::
    Arguments @ErrValue
    Uses edx, ecx, esi, edi, ebx

    call GetErrorMessage D@ErrValue
    call 'USER32.MessageBoxA' 0, eax, {'Warning !!!', 0}, &MB_OK__&MB_ICONWARNING__&MB_SYSTEMMODAL

EndP


This is not the final function yet, beca8use i need to understand why some converters returns valid (FCENOERR),but the  1st byte of he extension is 0FF (after it had a stack problem on mine GetReadNames function.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

TouEnMasm


If you have stack problem search in your code.
All is clear now for me.
The last problem is gone , I have succeed to export a rtf files to Word97 format
It is really stupid ghclass must be the same than in the registry,that is Word97 for the corresponding dll in the registry.
Errors must be filtered and there is to not take care of unknown errors.
After that all work.
Fa is a musical note to play with CL

TouEnMasm

Quote
To know which extension can be exported you need to use the Getread/Getwrite functions.
The GetReadNames and getWriteNames functions return something only with the html.cnv dll ,others dll return empt strings.
This point is tested with my code and c codes.
If you find others dll who answer something,put them here.

Another stupid thing,to know them read the value "Extensions" of the registry keys.
For each format,the Extensions values are given.

Fa is a musical note to play with CL

jj2007

Yves, Guga,
Compliments - you really take that seriously :t

guga

Reading from the registry is not a bad technique.

ReadNames and WriteNames only shows the extension IF the converter is registered. Ex: Lotus32.cnv who returns 0. But on my registry it do have the extension on the proper key.

html.iec does not return an empty string. It returns a pointer to the extension.


docx and docm extensions, the converter don´t have getreadname or getwritename functions
C:\Program Files\Microsoft Office\Office12\Wordcnvpxy.cnv


Write32.wpc, mswrd632.wpc returns 1, and it don´t grab the extensions, which make my assumption correct. When it returns 1 , the converter is not registered and, therefore,may not work.

On the opposite side, mswrd832.cnv, returns 1, have the extension on the registry, shows the extension on getwritenames, and so, it works. Also, it returs on getwritenames the pointer to the extension(which, don´t exists btw)


Other returns 0FFFFFFFB etc

See ? You can´t trust alone on the returned values of getReadnames/GetWriteNames according to the documentation, because each converter TRIES to make more or less similar to the sdk doc, but they fail badly on this. You need to use the registry values and also analyses the returned values from those functions (when they do exists, of course) to make a proper error case that works for all of them.

I´ll make a routine to grab all the return values from both functions and see what is going on. I´ll post it here too, when i finish. It maybe helpful for you.

Maybe for you analysing only 5 or 6 converters should solve the problem, but, it is definitely not the case for all users who have more then 5/6. I, for instance, have 18 of the newer version for different kinds of conversions. (I have more, but i forced the app to choose only the newer versions of each converter to use)
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

Tks JJ.


Yep, we are trying to make that crappy stuff works properly.  Some of them are really usefull and may be worth the effords.

I was original planning to make it simple, only for RTFtoHTML and vice-versa, so i can finish my downloader and parser for the msdn doc, but, now that i saw some converters doing a good job, it is good to make everything works fine for all purposes.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

Hi Yves

prepare for the mess  :greensml:

Those are the results of the returned values from GetReadName and GetWriteName exports


(Imported) Converter name: c:\WINDOWS\system32\HTML.iec    |   ReturnedValue: 0x1810A8h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  htm html htx otm
(Exported) Converter name: c:\WINDOWS\system32\HTML.iec    |   ReturnedValue: 0x1810A8h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  htm html htx

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\LOTUS32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  wk1 wk3 wk4
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\LOTUS32.CNV    |   ReturnedValue: 0xC00014h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\EXCEL32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  xls xlw xl5
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\EXCEL32.CNV    |   ReturnedValue: 0xC00014h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\write32.wpc    |   ReturnedValue: 0x1h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----
(Exported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\write32.wpc    |   ReturnedValue: 0x1h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\mswrd632.wpc    |   ReturnedValue: 0x1h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----
(Exported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\mswrd632.wpc    |   ReturnedValue: 0x1h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\mswrd832.cnv    |   ReturnedValue: 0x1h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  doc
(Exported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\mswrd832.cnv    |   ReturnedValue: 0xC00014h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\MACWRD32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  mcw
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\MACWRD32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x1810A8h    |   Ext.Data:  mcw

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WNWRD232.CNV    |   ReturnedValue: 0x182AC0h    |   Extension Addr:  0x182AC0h    |   Ext.Data:  doc
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WNWRD232.CNV    |   ReturnedValue: 0x182AC0h    |   Extension Addr:  0x182AC0h    |   Ext.Data:  doc

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WORKS432.CNV    |   ReturnedValue: 0xFFFFFFF8h    |   Extension Addr:  0x182ED8h    |   Ext.Data:  ---- Nothing here ----
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WORKS432.CNV    |   ReturnedValue: 0xFFFFFFF8h    |   Extension Addr:  0x182E90h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WORKS532.CNV    |   ReturnedValue: 0xC0001Ch    |   Extension Addr:  0x16C078h    |   Ext.Data:  wps
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WORKS532.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  wps

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\RECOVR32.CNV    |   ReturnedValue: 0x1h    |   Extension Addr:  0x16C078h    |   Ext.Data:  *
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\RECOVR32.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\WPFT632.CNV    |   ReturnedValue: 0x1h    |   Extension Addr:  0x16C078h    |   Ext.Data:  wpd doc
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\WPFT632.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\WPFT532.CNV    |   ReturnedValue: 0x1h    |   Extension Addr:  0x16C078h    |   Ext.Data:  doc
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TEXTCONV\WPFT532.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\TXTLYT32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ANS
(Exported) Converter name: c:\Program Files\Common Files\Microsoft Shared\TextConv\TXTLYT32.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ANS

(Imported) Converter name: c:\Program Files\Microsoft Office\Office10\WWPAB.CNV    |   ReturnedValue: 0x0h    |   Extension Addr:  0x16C078h    |   Ext.Data:  PAB
(Exported) Converter name: c:\Program Files\Microsoft Office\Office10\WWPAB.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WRD6EX32.CNV    |   ReturnedValue: 0xC0001Ch    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WRD6EX32.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  doc

(Imported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WRD6ER32.CNV    |   ReturnedValue: 0xC0001Ch    |   Extension Addr:  0x16C078h    |   Ext.Data:  ---- Nothing here ----
(Exported) Converter name: c:\PROGRA~1\COMMON~1\MICROS~1\TextConv\WRD6ER32.CNV    |   ReturnedValue: 0xC00054h    |   Extension Addr:  0x16C078h    |   Ext.Data:  doc




Returned value can be
1, 0 or any other regular error formats 0-1 to 0-14
A pointer to the extension (0x182AC0h, 0x16C078h etc)
A LongPointer to a Pointer to the extension (0xC00054, 0xC0001C etc), which may contain or not valid extensions

The "nothing here" string i made can refer to 2 situations:
a) The functions does not export or import
b) The function can import or export but it was not correctly registered

When the return value is a pointer (or a LongPointer) it is ALWAYS related to the extension,whose address may or may not contain the extension strings.

And things get a bit worst when you try to fetch the error messages with CchFetchLpszError export, because it will not report the correct error string all the time.

Now you see why is important also get the values from the registry and not to follow the SDK doc only? This is a way to compare to trhe results from GetReadNames/GetWriteNames to see either the converter was registered or not.

It is clear for me that who made those converters had no idea on the work of others and neither had a common official documentation for that. They simply was (and still are) using the old SDK doc, to make all sort of mess they want.

The return values should be kept simple: 0, 0-1, or other negative numbers (as the SDK paper refers to), and NEVER pointers to Addresses.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

TWell

Wordcnvpxy.cnv is in this package here

guga

Many tks tWell

I have it installed, but would be a good idea warn the user to go to the link if it is not registered, or making a download routine for that. The reason why it don´t show on the reports is because Wordcnvpxy.cnv don´t have GetReadnames and GetWriteNames exports
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

#115
Yves i changed the equates of error messages. There is no reason why to keep them on 16 bits. Since we may find error messages for other converters from 16 and 32 bits for the same error, the better will be keeping them all on 32 bits basis, and allow the app make a routine to find for the 16bits variation of them. I also created another equate called "FCEUNREGISTERED" to be used only with GetReadNames/GetWriteNames that have the same values as FCETRUE to keep the documentation more or less equal to the original SDK purposes. Eventually, i´ll writean SDK doc for these Apis to make it updated.

FCEINVALIDFILE 0FFFFFFFB
FCENOERR 0
FCENOMEMORY 0FFFFFFF8
FCEOPENINFILEERR 0FFFFFFFF
FCEOPENOUTFILEERR 0FFFFFFF4
FCEREADERR 0FFFFFFFE
FCETRUE 01
FCEUSERCANCEL 0FFFFFFF3
FCEWRITEERR 0FFFFFFFC
FCEWRONGFILETYPE 0FFFFFFF2
FCEUNREGISTERED 01


An error check for invalid functions (the ones that are not 0 or 1) can then simply be made as

    If_And eax >= &FCEWRONGFILETYPE, eax <= &FCEOPENINFILEERR, eax > &FCETRUE, ax <= (&FCEOPENINFILEERR  shr 16)
        mov eax 0 ; < ----- or call other error functions/messages/routines here
    End_If
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

Ok,guys...i guess i found it.


I made a routine for check for the returned values and i figured it out when it is really unregistered and when the app cannot import/export.

On the previous equate i made. I created a unregistered equate. In fact, it is related to the non existence of a import/export for that function. The trick is that, when both functions GetReadnames and GetWritenames returns this flag, it means that the converter cannot import/export anything, meaning that it is truly unregistered.

But, when GetReadNames or getWritenames contains at least one valid import/export then the converter is registered, but it can only import or export and not do both operations.

I´ll post the proper code for all that stuff as soon i finish and also will post the results from the report i previously made.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

TouEnMasm


My own code is finish.I have just to change the extension of the export file.
Instead of changing all the constantes errors code i have just made this.
or eax,0FFFF0000h ;and the rerror code is in 32 bits.
Fa is a musical note to play with CL

dedndave

what if it is positive ?

maybe something like this
    movsx   eax,ax

guga

HI dedndave

From the documentation the error messages are all in negative form (except for FCETRUE that carries a value of 1), but since the several different converters seems to emmit different returns, i´ll have to compare each export functions of them to see what is being returned to make the proper changes.

The idea is make a unique library that can hold all the converters functions and make them return the exact same values for the same situations. For example, there is no reason why getReadnames returns 0 when it finds a registered converter with a valid extension and on another one it returns an adress on the same situation (ie. it is registered and contains exports or imports)

Probably other exported functions from the converters behave on this same strange way. I believe that there are no more then 18 - 20 converters available from those packages, so the new ones should not be a problem, but the older ones, needs to be fixed. If i suceed, i´ll make a dll that can hold all of them (or the vast majority, at least), so we can use it on all aplications we want to build.

The idea is make it simple and easy configurable Apis for the user handle all possible situations of the converters currently available. If yu have more then those 18 converters, let me know. I would like to take a look at others that i don´t have here.
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com