Recent Posts

61

Using NASM / Re: windows x86 64bit help

« Last post by hockey97 on August 30, 2024, 01:43:27 AM »

I understood..

I am asking how to use LD the linker to link the ms-ABI for 64 bits.

I used  this batch commands:

Code: [Select]

cd "$(CURRENT_DIRECTORY)"
nasm -fwin32 $(FILE_NAME) -o $(NAME_PART).o
ld -mi386pe $(NAME_PART).o C:\Windows\SysWOW64\user32.dll
ld -mi386pe $(NAME_PART).o C:\Windows\SysWOW64\Kernel32.dll
gcc -m32 $(NAME_PART).o  -o $(NAME_PART).exe
$(NAME_PART).exe

This works. The asm program is 32bits and this works perfectly.

If I change  the -fwin32 to -fwin64    and -m32 to m-64  the  ld part won't work. It would show an error that this isn't an i386 image it would complain because
the ld is using 32bit I change the directory to the 64 bit dlls in windows and still get that same error.

my point is how do you link the files properly for a 64bit program.  I know the windows api is the same  winmain is the same regardless if you use asm, c++, python, any programming language
and regardless if it's 32 bit system 64bit system or a 128 bit system  the api stays the same.

my point is the why you link and assemble the program needs to be 32 bit if you're coding a 32 program and a 64bit if the program is supposed to be for a 64bit system.

I already know how to do this for 32bit systems.  i am asking how to do this for 64 bit systems.  There's nothing online about it.
Most say you don't need flags  or arguments if the GCC  and  LD version you downloaded is 64bits.  You just need the flags /. arguments if you want to make a 32bit version of the program you want for backwards capability purposes.

I am just asking how to assemble and link the files properly for GCC.

62

Using NASM / Re: windows x86 64bit help

« Last post by fredericopissarra on August 28, 2024, 05:09:23 PM »

There's a bit of confusion here... API stands for Application PROGRAM Interface and it is the same for both i386 and x86-64 modes on Windows. There's no Win64 API, just Win32 API. ABI stands for Application BINARY Interface and are different for i386 and x86-64.

x86-64 is the generic nomenclature for amd64 mode of operation of the processor (AMD nomenclature), or Intel 64 or IA-32e or the old EMT64 (3 of Intel's nomenclature), or x64 mode (Microsoft nomenclarure)... i386 mode is x86 (Microsoft) or IA-32 (Intel).

Take this simple program writen in C:

Code: [Select]

/* main.c */
#include <windows.h>

/* Protótipo do procedimento de janela */
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInst,
                     HINSTANCE hPrevInst,
                     LPSTR lpszCmdLine,
                     int nCmdShow)
{
  const static LPCSTR szClassName = "SimpleAppClass";
  HWND hWnd;
  MSG msg;
  WNDCLASS wc =
  {
    .style = CS_HREDRAW | CS_VREDRAW,
    .lpfnWndProc = WndProc,
    .hInstance = hInst,
    .hIcon = LoadIcon(NULL, IDI_APPLICATION),
    .hCursor = LoadCursor(NULL, IDC_ARROW),
    .hbrBackground = (HBRUSH)(COLOR_BTNFACE + 1),
    .lpszClassName = szClassName
  };

  RegisterClass(&wc);

  /* Este estilo criará uma janela "normal" que não pode
     ser maximizada ou ter seu tamanho alterado. */
  #define WINDOW_STYLE WS_OVERLAPPED  | \
                       WS_SYSMENU     | \
                       WS_VISIBLE     | \
                       WS_BORDER      | \
                       WS_MINIMIZEBOX | \
                       WS_CAPTION

  hWnd = CreateWindowEx( 0,
                         szClassName,
                         "My Simple App",
                         WS_OVERLAPPEDWINDOW,
                         CW_USEDEFAULT, CW_USEDEFAULT,
                         320, 100,
                         NULL, NULL,
                         hInst,
                         NULL );

  if ( ! hWnd )
  {
    /* Trata erro se não conseguiu criar a janela. */
    MessageBox( NULL,
                "Erro ao tentar criar a janela da aplicação.",
                "Erro",
                MB_OK | MB_ICONERROR);

    return 0;
  }

  UpdateWindow( hWnd );
  ShowWindow( hWnd, SW_SHOW ); /* Sempre mostra! */

  while ( GetMessage( &msg, NULL, 0, 0 ) )
  {
    TranslateMessage( &msg );
    DispatchMessage( &msg );
  }

  return msg.wParam;
}

Code: [Select]

// winproc.c
#include <windows.h>

LRESULT CALLBACK WndProc( HWND hWnd,
                          UINT uMsg,
                          WPARAM wParam,
                          LPARAM lParam )
{
  PAINTSTRUCT ps;
  RECT rc;

  // Processa mensagens...
  switch (uMsg)
  {
  // Ao destruir a janela...
  case WM_DESTROY:
    PostQuitMessage(0);
    return 0;

  case WM_PAINT:
    GetClientRect( hWnd, &rc );
    BeginPaint( hWnd, &ps );
      DrawText( ps.hdc, "Hello, world!", -1, &rc, DT_CENTER | DT_VCENTER );
    EndPaint( hWnd, &ps );
    return 0;
  }

  // Trata todas as outras mensagens.
  return DefWindowProc(hWnd, uMsg, wParam, lParam);
}
You can compile for 32 or 64 bits and it will work, unchanged, for Win95, Win98, WinMe, WinVista, WinXP, Win8, Win10 and Win11, in both 32 or 64 bits. This means the program interface is the same (Win32 API), but, of course the way stack is used, the arguments are passed to functions, registers used, etc, are different (MS-ABI for i386 or MS-ABI for x86-64).

63

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.

64

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?

65

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).

66

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?

67

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.

68

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!

69

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.

70

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.