Author Topic: A question for Habran/Nidud.  (Read 6141 times)

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 10583
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
A question for Habran/Nidud.
« on: July 10, 2016, 06:34:29 PM »
I was interested to see if HJWASM and Nidud's version can use the include files that Vasily designed. The libraries should be no problem as they are the same as normal Microsoft libraries as well as Pelle's libraries. With qWord's suggestion changing the "extern" to "externdef" the includes/libraries work OK with ML64.

Would either work with the format,


    externdef functionname:PROC
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

habran

  • Member
  • *****
  • Posts: 1228
    • uasm
Re: A question for Habran/Nidud.
« Reply #1 on: July 10, 2016, 07:54:27 PM »
It can work fine with call, however, invoke needs prototype
There is a difference between ML64 the macro invoke you are using and HJWasm invoke, because HJWasm checks parameters while the other one doesn't
Cod-Father

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 10583
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: A question for Habran/Nidud.
« Reply #2 on: July 10, 2016, 08:33:05 PM »
What a shame, its a lot more work to produce an exhaustive list of prototypes. I gather the libraries would be no problem.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

habran

  • Member
  • *****
  • Posts: 1228
    • uasm
Re: A question for Habran/Nidud.
« Reply #3 on: July 10, 2016, 08:58:21 PM »
I can see that you world is upside down, where good is bad and bad is good, no wander why, we are upside down here in OZ, I have been here only 24 years, maybe not long enough to catch up that perception :biggrin:
It would be possible to make it work in bad way, however, I am not gonna do it 8)
I remember the scene from Groundhog Day when Phil (Bill Murray) says to Ned (Stephen Tobolowsky) : "I would love to have a cup of coffee with you, but I am not gonna do it."
Cod-Father

nidud

  • Member
  • *****
  • Posts: 2388
    • https://github.com/nidud/asmc
Re: A question for Habran/Nidud.
« Reply #4 on: July 10, 2016, 09:12:42 PM »
deleted
« Last Edit: February 25, 2022, 11:56:45 AM by nidud »

nidud

  • Member
  • *****
  • Posts: 2388
    • https://github.com/nidud/asmc
Re: A question for Habran/Nidud.
« Reply #5 on: July 10, 2016, 09:36:06 PM »
deleted
« Last Edit: February 25, 2022, 11:56:58 AM by nidud »

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 10583
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: A question for Habran/Nidud.
« Reply #6 on: July 10, 2016, 11:21:15 PM »
It was more a comment that its easy enough to do a full set of include files for something as crude as ML64 as it has no type or size checking. Its not a problem for my generation as manual coding was normal but I do see that advantage of at least argument count checking for people who do not have that background. It was easy enough to get the argument count in STDCALL functions from the win32 libraries but the win64 libraries use a different notation so there is no an easy technique to get the argument count.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

rrr314159

  • Member
  • *****
  • Posts: 1378
Re: A question for Habran/Nidud.
« Reply #7 on: July 10, 2016, 11:47:44 PM »
I was interested to see if HJWASM and Nidud's version can use the include files that Vasily designed. The libraries should be no problem as they are the same as normal Microsoft libraries as well as Pelle's libraries. With qWord's suggestion changing the "extern" to "externdef" the includes/libraries work OK with ML64. Would either work with the format,

    externdef functionname:PROC

It can work fine with call, however, invoke needs prototype
There is a difference between ML64 the macro invoke you are using and HJWasm invoke, because HJWasm checks parameters while the other one doesn't

turn off the keyword "invoke" and use Vasily's invoke macro instead of the HJWasm invoke
I am NaN ;)