Firebird ошибка 193

Кто-то покорежил птичке екзешник?

Причем тут экзешник? Три раза переставил FB

Pablov писал(а):Причем тут экзешник?

Нерусские буквы при чтении пропускаешь автоматически? Нехорошо…

Как приложение сервер запускается?

Dimitry Sibiryakov писал(а):Error 193: %1 is not a valid Windows-based application.

Это сообщение не имеет под собой почвы. Я достаточно разбираюсь в формате PE файлов, есть инструментарий, который уверенно говорит про fbserver.exe что это Microsoft Visual C++ 7.0
Про вирусы. Странно, что они ополчились на один Firebird Server, а других не трогают
Какие еще будут предположения

Dimitry Sibiryakov писал(а):Нерусские буквы при чтении пропускаешь автоматически? Нехорошо…
Как приложение сервер запускается?

Нерусские буквы немного знаю (см. пост выше)
Как приложение сервер не запускается, молча падает
Усли запускать из Панели управления, через Firebird 2.0 Server Manager тогда ругается «Error 193: %1 is not a valid Windows-based application»

Pablov писал(а):Это сообщение не имеет под собой почвы. Я достаточно разбираюсь в формате PE файлов
Какие еще будут предположения

Забавно… Сам послушай как это звучит: «Я считаю что этот экзешник нормальный, а винда упрямо твердит, что нет. Что не так с FB?»

При чем тут вообще FB, если ошибку выдает Windows?

Pablov писал(а):

Dimitry Sibiryakov писал(а):Error 193: %1 is not a valid Windows-based application.

Это сообщение не имеет под собой почвы. Я достаточно разбираюсь в формате PE файлов, есть инструментарий, который уверенно говорит про fbserver.exe что это Microsoft Visual C++ 7.0

Про почву ты Билли расскажи.
Зависимости поверял ? Может dll какая окривелла…

hvlad писал(а):Про почву ты Билли расскажи.
Зависимости поверял ? Может dll какая окривелла…

dll какая, системная, дык все остальное работает? А если dll Firebird’а, то я уже писал выше, что переставил (с деинсталяцией) Firebird с 1.5 на 2.0 перед этим почистил реестр. Результат тот же.

Ладно, спасибо всем за ответы, думал кто сталкивался с подобной траблой. Буду думать…

перед этим почистил реестр.

что там чистить??? Ну что там чистить или «инсталлировать»?
Ты читал например www.ibase.ru/devinfo/inst_manual.htm ?

можно было вообще бросить часть файлов от 2.0 поверх 1.5, и все бы и так работало.
Так что пробуй на другой машине. А если с этой справиться не сможешь, то я подозреваю, что тебе придется винду переставлять.

А мож этого птаха на ХР ещё никто не ставил

ну вы прямо, я даже не знаю. разве можно в нас так сомневаться?

I have Delphi 10.2 and Firebird 2.5 installed on my development machine. The database applications that I develop in this setup function properly.

I transferred a program and its corresponding database from one computer to another, both running Windows 10. On the new computer, I installed Firebird and also installed sql manager lite for InterBase/Firebird. This program successfully opens and displays the data from the database. However, my Delphi program encounters an error when trying to open the database. The error message states ‘Unable to load dbxfb.dll (error code 193). It is possible that the file is missing from the system path’.

I have placed the dbxfb.dll file in various locations, including the program directory, the database directory, windows\system32, C:\Program Files (x86)\Firebird, and others. However, the message remains unchanged. On my development machine, the presumed path (i.e., system properties\advanced\environment variables) only includes the %USERPROFILE%\AppData\Local\Microsoft\WindowsApps directory. On the other computer, I attempted to add C:\Program Files (x86)\Firebird, but it did not resolve the issue.

Where should the dbxfb.dll file be placed, or how can I specify the location for my program to locate it?

Regarding the ‘bitness’ issue, it is important to note that both computers are 64 bit. However, in the Delphi Project Options dialog box, only the 32-bit option is available. Although I have adjusted the program’s compatibility setting to Windows 8, it did not have any impact on the missing dll problem.

In addition, the incorrect version on the target machine is 1,412kb in size and has a date of 13/11/2015 1:55. This particular version is sourced from C:\Program Files (x86)\Embarcadero\Studio\17.0\bin64, confirming that it is indeed the incorrect version.

The directory C:\Program Files (x86)\Embarcadero\Studio\17.0\bin contains a smaller version of the file, measuring only 278kb in size. This file has the same date but was created at 06:55. When the smaller file is copied to the target machine and the program is executed, a new error message is displayed: an I/O error occurred during the «@1» operation for file «@2». The error is related to the attempt to open the file.

Please refer to the Microsoft documentation for the system error codes in the range of 0-499. You can find this information at the following URL: «https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes».

ERROR_BAD_EXE_FORMAT

193 (0xC1)
%1 is not a valid Win32 application.

The issue, as indicated by Mark, is indeed related to the bitness.

Upon executing the code, an error occurs.


[WinError 193]% 1 is not a valid Win32 application


    from ctypes import *
    mydll = windll.LoadLibrary(r"C:\Windows\SysWOW64\kernel32.dll")
    mydll.Beep(2000,500)

In summary, utilize
dll = WinDLL('kernel32')
as it is located within the default DLL search path.

To ensure compatibility, it is necessary to utilize DLLs that correspond to the appropriate Python version, using 32-bit DLLs for 32-bit Python and 64-bit DLLs for 64-bit Python.

Contrary to intuition, the 64-bit Windows version of \
\ \ \ \ C:\Windows\SysWOW64\
\ \ \ includes DLLs that are suitable for running 32-bit applications, while \
\ \ \ \ C:\Windows\System32\
\ \ \ includes DLLs specifically designed for 64-bit applications.

Regardless of whether you are using 32-bit or 64-bit Python, it is recommended to always use \
\ \ \ \ C:\Windows\System32\
\ \ \ when hard-coding the path. This is because 32-bit applications that were initially designed for 32-bit Windows will attempt to open \
\ \ \ \ C:\Windows\System32\
\ \ \ ; however, when executed on 64-bit Windows, the access will be automatically redirected to \
\ \ \ \ C:\Windows\SysWOW64\
\ \ \ for backward compatibility purposes.

PyCharm displays the following error message:
WindowsError: exception occurred due to an access violation while reading 0x000000504D414C43.

The issue arises exclusively in Pycharm. When executing the python script through Windows Powershell, an error message appears stating «WindowsError: [Error 193] %1 is not a valid Win32 application». I examined the debugger and observed that a value is being passed, yet occasionally it results in null pointers. Initially, I suspected that the problem was related to accessing the array incorrectly. However, even when I simply return the value 7 (as shown at the bottom) and disable all of the code, the issue persists as described.

Questions:

1) Do you have any solutions?

2) Did I set up the DLL properly?

3)Any suggestions?

Thank you so much for your help.

Here is my C++ code:

#include 
#include 
#include 
#include "external_lists.h"
extern creation_object A1[];
extern creation_object  A2[];
extern int A1size;
extern int A2size;
#define DLLEXPORT extern "C" __declspec(dllexport)
DLLEXPORT int get_creation_data(std::string needed_name){
int A1_size = ( A1size/ sizeof(A1[0])) ;
int A2_size = ( A2size / sizeof(A2[0]))  ;
for (int i = 0; i < A1_size; i++) {
    if (A1[i].name == needed_name) 
    { 
    return A1[i].value->section; 
    }
}
return 7;
}

Here is my python wrapper:

import os, sys, re
from ctypes import *
def get_creation_values(value_name):
  trimdll = CDLL('C:\\Documents\\creation.dll')
  return valuedll.get_creation_data(value_name)
if __name__ == "__main__":
  val = get_value('CLAMP')
  print(val)

Overall goal:

I am unable to modify a substantial file that I need to access in C++. Within this C++ file, there are extensive lists that I must iterate through and return a value to a python script.

QuillBot only supports C types. If necessary, you can pass a byte string as
const char*
and assign it to a
std::string
. Below is a complete and functional example:

The code provided is written in C++ and is located in a file named «test.cpp».

#include 
#define DLLEXPORT extern "C" __declspec(dllexport)
DLLEXPORT int get_creation_data(const char* name) {
    std::string needed_name(name);
    if(needed_name == "Armaja")
        return 1;
    return 0;
}

Python code

from ctypes import *
def get_creation_values(value_name):
  trimdll = CDLL('test')
  trimdll.get_creation_data.argtypes = [c_char_p]
  trimdll.get_creation_data.restype = c_int
  return trimdll.get_creation_data(value_name)
if __name__ == "__main__":
  val = get_creation_values(b'Armaja')
  print(val)

Output:

1

One can specify the argument types and return value of the DLL function to enhance error detection. An illustration of this is when attempting to pass a Unicode string (
'Armaja'
) instead of a byte string (
b'Armaja'
) in Python 3 syntax.

Traceback (most recent call last):
  File "C:\test.py", line **** 
    val = get_creation_values('Armaja')
  File "C:\test.py", line 7, in get_creation_values
    return trimdll.get_creation_data(value_name)
ctypes.ArgumentError: argument 1: : wrong type