I have been given the task to upgrade an existing 16 Bit Desktop application originally written in GFA Basic.
I want to know if there is a possibility to access the functions inside these 16 Bit Dlls via C/JNI (or any other programming language).
I guess, I have to write some sort of an intermediate DLL to access the functionalities from a Java class (or any other language).
For example
DLLTEST has the implementation of the functions
$Library
'LNK Exe d:\DLLtest.dll
Procedure LIBMAIN(hInst&, DSeg&, HpSz&, lpCmd%)
q_dllname$ = "DLLtext.dll"
RETVAL 1 ' If LIBMAIN is used, then RETVAL must be TRUE
Return
Procedure WEP(SysExit&)
' ##############################################
// SysExit = 1 - ExitWindows
// SysExit = 0 - DLL vrijgegeven
RETVAL 0 ' ???????????
Return
Procedure TextTest(dc&)
$EXPORT TextTest
SETDC dc&
RGBColor 0
Local t$ = "Hello world" + Chr$(0)
Text 10, 10, t$
Beep
~TextOut(dc&, 10, 50, V:t$, Len(t$))
Beep
Return
The above dll file is in turn used by TESTTEXT.exe
// destination exe file
'LNK Exe d:\testtext.exe
DLL #7, "dlltest.dll"
DECL LONG TextTest(W)
ENDDLL
OpenW # 1
h& = Win(1)
SETDC GetDC(h&)
' RGBCOLOR 0
' GRAPHMODE R2_COPYPEN
~##TextTest(_DC())
KeyGet k%
CloseW # 1
FreeDll 7
End
I want to rewrite this TESTTEXT.exe using Java/C (or any other moder programming language). I guess, I need to build a bridge between this dll and the new exe by building another dll.
I was hoping to get some help about writing this intermediate dll.
Also, let me know if this kind of solution makes sense!
Your help would be highly appreciated.
Thanks you for your time.
Using a 16-bit DLL from a 32-bit application involves what Microsoft calls (called) "flat thunking". Flat Thunking is available only in the 16/32-bit hybrid versions of Windows (Windows 95, 98, 98SE, Me).
What you want is not supported on any reasonably current version of Windows.
I agree with Jerry. In the meantime you might start looking at this post:
http://www.atari-forum.com/viewtopic.php?f=69&t=4826&start=20
Related
I try get IShellItem for a file to copy it with IFileOperation COM interface from system directory to another directory. I must use exactly IFileOperation COM interface for this purpose.
When I specify full filename - return value from SHCreateItemFromParsingName() was ERROR_FILE_NOT_FOUND, but file present in the directory. When I delete filename from path below and use only folder path - all seems good, return value is S_OK.
//...
CoInitialize(NULL);
//...
WCHAR szSourceDll[MAX_PATH * 2];
wcscpy_s(szSourceDll, MAX_PATH, L"C:\\Windows\\System32\\sysprep\\cryptbase.dll");
r = CoCreateInstance(&CLSID_FileOperation, NULL, CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER | CLSCTX_INPROC_HANDLER, &IID_IFileOperation, &FileOperation1);
if (r != S_OK) return;
FileOperation1->lpVtbl->SetOperationFlags(FileOperation1, FOF_NOCONFIRMATION | FOFX_NOCOPYHOOKS | FOFX_REQUIREELEVATION);
r = SHCreateItemFromParsingName(szSourceDll, NULL, &IID_IShellItem, &isrc);
//...
CoUninitialize();
//...
Why this code, written in C, not working with filenames. How can I create IShellItem instance for file in system folder to copy it?
P.S.
Windows 7 x64, C, Visual Studio 2015, v140 platform toolset, additional dependencies: Msi.lib;Wuguid.lib;ole32.lib;ntdll.lib
P.P.S
It's properly work with files in user`s directories...
Assuming your application is compiled as a 32-bit application and running on a 64-bit OS, a file not found error is probably correct because your application is redirected to the 32-bit system directory (%WinDir%\SysWoW64).
In most cases, whenever a 32-bit application attempts to access %windir%\System32, %windir%\lastgood\system32, or %windir%\regedit.exe, the access is redirected to an architecture-specific path.
For more information, see File System Redirector on MSDN.
You could temporarily turn off redirection in your thread but it is not really safe to do this when calling shell functions, only functions in kernel32. If the API you are calling internally uses LoadLibrary and/or COM then the API might fail because it will be unable to load from system32 while redirection is disabled.
You can also access the native system32 directory with the %WinDir%\SysNative backdoor. This only works in 32-bit applications on 64-bit Vista+ so you must do some version detection.
,Hello, friends! I've been trying to add compatibility with Lua 5.1 to a library I'm working on and that's written, originally, to Lua 5.3. Everything was going considerably fine until now.
I've stumbled with a behavior I have absolutely no clue about the cause. Here's the thing: apparently, I can't read binary files properly on Lua 5.1. For the sake of clarity, running this test snippet produces different outputs depending on the version it's ran.
local f = io.open("test.bin", "wb")
local t = {}
for i=1, 256 do t[i] = i-1 end
local unpack = unpack or table.unpack
local str = string.char(unpack(t))
f:write(str)
f:close()
f = io.open("test.bin", "rb")
local buffer = {}
for line in f:lines() do
print(#line)
for i=1, #line do
buffer[#buffer+1] = string.byte(line:sub(i,i))
end
end
print('Total:', #buffer)
f:close()
Using Lua 5.1:
245
Total: 245
Using Lua 5.3:
10
245
Total: 255
So, the way I see it is that version 5.1 simply jumps the first "line" of the file for some reason.
Any help will be profoundly appreciated.
This was a bug in Lua 5.1 and Lua 5.2 that was corrected in Lua 5.3.
Anyway, don't use f:lines() with binary files. Instead, read the whole file with f:read("*a")or read it by blocks.
I need to add some board-specific code to a Linux kernel which I am building.
(I know I should be using device-tree already, but the driver I'm inspired by doesn't and I'm already learning a dozen new things before breakfast. Adding device-tree will also add another set of changes to debug. Once I have my platform-driver/drivers working using a board file, I will convert them to device tree.)
I have a file called arch/arm/myboard/myboard.c.
Where do I find existing board files in make menuconfig? (Such as http://lxr.free-electrons.com/source/arch/arm/mach-imx/mach-mx31ads.c?v=4.4 ?)
How do I make my board appear here also.
Take a look at the Makefile in the same directory. For mach-mx31ads.c, it has,
# i.MX31 based machines
obj-$(CONFIG_MACH_MX31ADS) += mach-mx31ads.o
The Kconfig has a corresponding entry,
config MACH_MX31ADS
bool "Support MX31ADS platforms"
default y
select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_SSI
select IMX_HAVE_PLATFORM_IMX_UART
select SOC_IMX31
help
Include support for MX31ADS platform. This includes specific
configurations for the board and its peripherals.
Adding these will give your board a Kconfig menu item and build the file. The only other missing piece is a machine type. You need to add this to arm/tools/mach-type which is processed by the kernel makefile, using the gen-mach-types script, to create a generated/mach-type.h. You use this in your board file to create a static machine description (put in a special section).
MACHINE_START(MX31ADS, "Freescale MX31ADS")
/* Maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
.map_io = mx31ads_map_io,
.init_early = imx31_init_early,
.init_irq = mx31ads_init_irq,
.init_time = mx31ads_timer_init,
.init_machine = mx31ads_init,
.restart = mxc_restart,
MACHINE_END
The machine_desc structure is found in arch.h. You don't need to add all the elements as they won't be called if not present. The kernel init looks a the machine ATAG and iterates through the sections to match the machine that the boot loader passes in. Locating the machine_desc is done in assembler very early in the linux boot.
I'm writing a windows (MS) application to get the name of the process of the active window.
On a desktop PC running 32-bit Windows XP Professional the application runs as expected. But on a laptop machine with a 64-bit Windows 7 Professional OS the does not work as expected. For certain processes an invalid handle is returned. I get the same results on an ultrabook running Windows 8.1 64-bit.
The relevant code snippet is as follows:
DWORD dwThreadID, dwProcessID;
GUITHREADINFO gti;
HANDLE hProcess;
char szProcessFileName[MAX_PATH] = {0};
gti.cbSize = sizeof(GUITHREADINFO);
GetGUIThreadInfo(0, >i);
dwThreadID = GetWindowThreadProcessId(gti.hwndActive, &dwProcessID);
hProcess = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, dwProcessID);
// Get the name of the process (no error checking for brevity)
GetModuleFileNameEx(hProcess, NULL, szProcessFileName, MAX_PATH);
When the application runs in the non-Windows XP OSes, as stated above, for certain processes OpenProcess and GetModuleFileNameEx fail. GetModuleFileNameEx typically fails with ERROR_PARTIAL_COPY (error code: 299) or ERROR_INVALID_PARAMETER (error code: 87) whereas OpenProcess fails with ERROR_INVALID_HANDLE (error code: 6)
Not sure what's going on. Any help is greatly appreciated. I wonder if it has to do with user permissions.
The source code is compiled as a 32-bit application on a 64-bit machine running Windows 7 Pro x64.
It's a bit of a long read but try... this for starters.
If you are running on XP or above, the recommended workaround to get at the 64-bit process image path from a 32-bit process, is to use the newer GetProcessImageFileName which gets the path (via ProcessImageFileName (27) process information class of NtQueryInformationProcess). The wow64 layer does not do much this time because it is just a unicode string. However this function has a downside – the path returned is of the form /Device/HarddiskVolumeX instead of DOS style drive letter based paths.
Note how the one error was trying to tell you that only 32-bits of a 64-bit address was copied into your pointer. The article describes it better than I can.
I'm a newbie in Qt (although I have some experience with C/C++/Java/PHP). I'm trying to migrate my older program that use PostgreSQL database into Qt GUI. I'm using PostgreSQL v2 and have downloaded the recent QT 5.3.0 (for MinGW 32-bit).
I created an example widget application, called Anu. The Anu.pro file looks like this :
QT += sql
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = Anu
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp
HEADERS += mainwindow.h
FORMS += mainwindow.ui
And the mainwindow.cpp looks like this :
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QSqlDatabase>
#include <QtSql>
#include <QMessageBox>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}
MainWindow::~MainWindow()
{
delete ui;
}
void MainWindow::on_pushButton_clicked()
{
QSqlDatabase db = QSqlDatabase::addDatabase("QPSQL");
db.setHostName("localhost");
db.setDatabaseName("basicaccount");
db.setUserName("postgres");
db.setPassword("root");
db.setPort(5435);
bool ok = db.open();
if(ok != true)
{
QMessageBox::information(this,"Connection","Connection Failed!") ;
}
else
{
QMessageBox::information(this,"Connection","Connection OK!") ;
QSqlQueryModel model;
model.setQuery("select * from invoice ");
//ui->tableView->setModel(&model);
QMessageBox::information(this,"Information","This Message box is needed in order to see the rendered tableview!") ;
}
}
The error in compile shows QSqlDatabase: QPSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7. I tried to build the plugin using the information here : http://qt-project.org/doc/qt-5/sql-driver.html. I opened the command prompt for Qt and put this :
cd E:\Qt\Qt5.3.0\5.3\mingw482_32\plugins\sqldrivers\psql
qmake "INCLUDEPATH+=E:\Program Files\PostgreSQL\9.2\include" "LIBS+=E:\Program Files\PostgreSQL\9.2\lib\libpq.lib" psql.pro
nmake
The problem is, I can't find the src folder or psql on folder sqldrivers. I've only found qsqlpsql.dll on that folder, and everytime I used it it says directory can't be found. Also, what's 'psql.pro' mean?
Thanks a lot for any help.
The most easy way, you need the following;
Depending on your application, 64 or 32 bit
If postgresql is 64 or 32 bit it doesn't matter, as the mingw is configured for 32 bit applications.
You need the 32 bit dlls,
If your version of postgre is 32 bit, then copy following dll's from your postgresql installations bin folder libeay32.dll, libintl.dll, libpq.dll, and ssleay32.dll, to your qt version mingw bin folder, now your program should work
If postgresql is 64 bit, the the included dll's doesn't work out of the box these are 64 bit !
You can still use 64 bit postgresql DB, no problem but you need the 32 bits dll's for your application.
There are more sophisticated ways to do this but to kick start your application this is considered the fastest.