Recent Posts

11

Using NASM / Re: windows x86 64bit help

« Last post by hockey97 on August 27, 2024, 07:08:32 PM »

Surely it's better to learn the Windows 64-bit API for 64-bit Windows apps? Does the Win32 API even still exist in Windows 11?

Yes, for windows api you can write 32 bit programs  and 64 bit programs.

WoW64 folder in windows folder holds the windows api files for 32bit programs.
The System32 folder holds the windows api that's for x86-64 programs.

There's no api for strictly fore 64 bit . However, in the future  Microsoft is going to have to rewrite or make major changes to the windows API for future cpus.

Intel already announced the cpu's they're working now on is going to be a strict 64bit chip. No backwards capability.  They made a new ISA which is strictly 64bits.

That's where the future is going anyways. However, you're going off topic. I am trying to make that commands to compile the files to a 64 bit program. an x86-64 program.
How would that be done?  Or do I list the files in where I listed the object files and don't need to use flags or arguments to compile it.

12

Using NASM / Re: windows x86 64bit help

« Last post by hockey97 on August 27, 2024, 06:52:38 PM »

Code: [Select]

[quote author=fredericopissarra link=topic=3932.msg16182#msg16182 date=1724765437]
There is NO Win64 API on Windows. There is MS ABI for x86-64 (there's a subtle difference).
[/quote]

There's a 64bit version. I know it's not  a  64bit version but I am asking for what you said. x86-64.
They will have to have one in the future though because Intel is ditching backwards capability their future cpus will have a 64BIT ISA.

but I am talking what you said.

I know this works for 32 bit programs:
[[removed]
this is the cmd commands.  This works with no issues.

However, don't know how I can do this for a 64 bit  program.

I know the WOW64 is for 32 bit programs for the windows api files.
The 64 bit files reside in System32 folder.
My point is what commands would be used to do the same exact thing but for 64bit programs?

13

Using NASM / Re: windows x86 64bit help

« Last post by fredericopissarra on August 27, 2024, 01:30:37 PM »

There is NO Win64 API on Windows. There is MS ABI for x86-64 (there's a subtle difference).

14

Using NASM / Re: windows x86 64bit help

« Last post by debs3759 on August 27, 2024, 05:55:11 AM »

Surely it's better to learn the Windows 64-bit API for 64-bit Windows apps? Does the Win32 API even still exist in Windows 11?

15

Using NASM / windows x86 64bit help

« Last post by hockey97 on August 26, 2024, 06:09:17 PM »

What can I do to use windows 32 api for 64bit programs?

I want to know how to link the user32.dll and kernel32.dll properly and what else is needed to support using
windows 32 api to make a gui  window?

I am using nasm and gcc compiler

Thanks in advance.

16

Using NASM / Debugging macroses

« Last post by Korybut on August 13, 2024, 10:27:10 AM »

Hello!

I am implementing several macroses right now and debugging them is kinda painful since I run debugger for compiled code and then verify if my macroses work correctly. IMO the great option is to be able to see the listing with already executed macroses, howerer '-l' option produces different output which is of no particular use unfortunately.

Many thanks in advance!

17

Other Discussion / Re: I just found that Microsoft publicly released the source code for old DOS!

« Last post by ben321 on August 03, 2024, 08:35:03 PM »

5 years ago...
The question is: Why M$ never released MS-DOS 6 or Windows 3.1 sources? (and never will!)

Just checked that GitHub again and found they now have DOS 4.0 and DOS 4.0-ozzie (I don't know what the ozzie version even is). They seemed to skip all of DOS 3.x versions though.

18

Programming with NASM / Re: How do I write an EFI application in NASM?

« Last post by ben321 on August 03, 2024, 08:28:13 PM »

A small example for i386 mode, assuming by "application" you mean "bootloader":
Change main to _start if you want to avoid -e option with ld.

PS: EFI_BOOT_SERVICES.Print() and EFI_BOOT_SERVICES.ReadKeyStroke() don't exist. Print() is a wrapper function, defined in a external library, to EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() and ReadKeyStroke() is a function on EFI_SIMPLE_TEXT_INPUT_PROTOCOL. They are available at interfaces pointed by ConIn and ConOut, at EFI_BOOT_SERVICES.

I strongly recommend to read UEFI specification (download, at least, version 2.7 - most BIOSes support this one). There you can find the entire documentation of how EFI works and how to use it in i386, x86-64, ARM, and other platforms.

The link you provided to the UEFI specifications doesn't work. Please fix your link.

19

Using NASM / Re: Call abs_addr-$

« Last post by suncowiam on July 20, 2024, 04:45:03 AM »

I found a possible solution:

SECTION .text
  call 60000h-next_addr-$$
next_addr:
  mov rax, 1

When compiled, the relative offset will equate to 60000h.  Does anyone else have any better solutions?

Thanks

20

Using NASM / Call abs_addr-$

« Last post by suncowiam on July 20, 2024, 12:22:24 AM »

Is there an argument to calculate the target address - next inst to help calculate relative addresses?

I need to compile a specific relative address in a call or jmp instruction.