all dos base application experts here is one thread i am creating.
i would like your opinion for this issues
i found one problem in windows xp or any windows system higher to windows 98
i have a dos base application which runs perfect on windows 98 but when i am running it on windows xp or other system it is showing me following error message
16 bit Ms-Dos Subsystem
An application has attemped to directly access the hard disk, which cannot
be supported. This may cause the application to function incorrectly.
Choose close to terminate the application
as i can run it by pressing ignore but want to remove this error message
second thing i found is dos base printing
printing is not working properly
as it prints some part then it pause for some time and then resume printing
so how to solve these problems.
An application has attemped to directly access the hard disk, which cannot be supported.
This error means exactly what it says. Older versions of Windows including 95/98/Me gave DOS programs full control over the system, meaning they could access hardware as they wished -- while this maintained compatibility with older programs, it could also cause the entire OS to crash if this one program did something wrong.
The Windows NT family (including XP and all newer versions) runs DOS programs in an NTVDM (NT virtual DOS machine) which does not have direct access to hardware, and any attempt by programs to access such things will cause the program to be terminated. Of course, you can ignore the error, but your program will likely not work correctly.
Related
*THIS HAS BEEN EDITED, SEE BOTTOM. I CHANGED THE TITLE TO BETTER REFLECT THE PROBLEM.**
I have an old vb6 application that I put on a windows 2016 server and been having issues with dependency files. I ran process monitor and started putting the dll files in the locations where it is looking at, most of them have cleared up.
I'm getting one that I cant find on the old win 2000 box or anywhere else: wow64log.dll
Where can I can get this file? I attached pics of proc mon and the list of dependencies that the app is requiring. any direction would be appreciated. third pic is the actual error when trying to open the app. edit added the dependency walker screen shot
EDIT***
so I have narrowed down the issue and it boils down to an ADO connection. I cant seem to connect on windows server 2016 using ADO. I suspect it has something to do with the connection string, but what baffles me is why does this work on a win 10,1803 box and not on windows server 2016 1607 ?
this is basically my issue - https://social.msdn.microsoft.com/Forums/SECURITY/en-US/f1eee40b-6ab2-445f-a361-ae965439273a/run-time-error-214746725980004005-for-using-adodbconnection?forum=isvvba
I suspect that this is not an actual error in the runtime of your program, If you are only looking at Procmon, be aware that it shows a lot of stuff and sometimes not all the "errors" there are really relevant. For instance, it will often show how Windows functions look in a long list of search paths, each failing in turn, before that actual location of a DLL is detected.
In this case, it seems most likely that a missing wow64log.dll is harmless and apparently, totally normal.
"WoW64" is the Windows subsystem which runs 32 bit programs inside the 64 bit operating system. ("WoW" stands for "Windows-on-Windows".)
According to the reference WoW64 Internals describing how this subsystem is initialized:
wow64!ProcessInit
...
It … tries to load the wow64log.dll from the constructed system
directory. Note that this DLL is never present in any released
Windows installation (it’s probably used internally by Microsoft for
debugging of the WoW64 subsystem). Therefore, load of this DLL will
normally fail. This isn’t problem, though, because no critical
functionality of the WoW64 subsystem depends on it.
Although that article is talking about the ARM64 architecture (which AFAIK is not what most PCs would be using) it sounds like much of the WoW64 system is similar to normal PCs.
I tried to learn "Lena's reversing for newbies", when some trouble arise.
I start Pixtopian Book with ollyDbg, then try to have MessageBox with message about uregistered version.
Then i switch to OllyDbg, stop program executing and press "Alt+F9" for "Back to user mode" which stop the program after it exit from DLL.
But after this program does not work, it's frozen and does not respond to my actions.
If i turn off "Back to user mode" program normally work.
What's the problem? Can i try to use "Back to user mode" in IDA (uses WinDbg) or some other debugger and How i can do this? Can i repair it function in OllyDbg?
P.S. It's like the program stopped and didn't run after use "ALT+F9".
/Sorry for my English, i'm just learning ;-)/
First of all, Ollydbg is meant for 32 bit platform. It means that it will run only on a 32 bit OS and can only debug 32 bit apps.
In x64 Operating Systems (specifically Windows) there is a feature called compatibility mode that lets you run 32 bit apps. The 32 bit code is either run by emulation or natively (when the hardware itself implements the instruction set and then it is called x86-64).
So, when you try to run Ollydbg in a x64 environment it will run, but you will experience problems like the one you are facing. It occurs because Ollydbg is run in an emulation mode. Being a debugger it needs access to the registers and other system structures, which it is denied. What it can see is a virtual image of the system.
So the solution to the problem is using a Virtual Machine.
You would install a 32 bit OS in it and debug the app using Ollydbg. As far as Virtual Machines are concerned, I would recommend VMWare. You can use either the workstation or player version. The latter is free but does not support snapshots.
Other solutions are Virtual Box, Parallels Workstation and Microsoft Virtual PC.
The disadvantages of them are that Virtual Box does not support hardware breakpoints, Parallels Workstation is no longer supported as of 2014 and moreover there you would get a BSOD if you try to single step through FPU instructions. I have not tested Virtual PC though.
Note : Ollydbg does not supports x64 but its author is working on a x64 version.
I just learned how to update changes to the exe file for ollydby v 2.01e.
suppose I wished to change a jl command to a jmp; do this by clicking the executable modules button, choose the file and right click to view the file. then record the changes and save file. The saved file also has a backup in case something goes wrong.
I just did a thorough learning of the pixtopian file. When I downloaded
that tutorial I get the file pixtopian107.exe only. Since it didn't agree with the tutorial I investigated further. That file is an installation file. It produces a regular pixtopian.exe file which is the file you wish to play with.
I also noticed that in running the file it never enters the main module.
this is because of the TLS callback. right now I am trying to learn how
to overcome this which is how i came to this site in the first place.
I am using ollydbg vs2.01e very effectively.
Another thing, in vs 2.01e I am still trying to save changed data. Until I succeed I am recording the changes in the exe files using hex editor.
From my experience I can tell that this functionality won't work on Windows 7.
On Windows 7 64bit --> Won't work at all.
On Windows 7 32bit --> Will work partially, but only when using option "File>Attach" in OllyDbg.
For me, best solution was to use Windows XP 32bit, then it worked fine.
Working on a game atm using Ruby, but due to the nature of how the game is coded Windows XP is proving to be a issue, as various tweaks can be done to make you faster than other players
so my intentions are to upon loading of the game detect if you are running windows XP, and if so fail to load any further.
This may seem harsh, but the advantages XP gives over Vista or Win7 etc is vast and is unbalanced.
Can any one help?
Here you find some solutions on how to detect the operating system:
How can I find which operating system my Ruby program is running on?
But I think, it only tells you, if it is Windows or not. So you have to do a second step:
If it is Windows, you could call the system command ver to detect the Windows Version (As you might know, system commands can be called using the `-Symbol).
`ver`
More information about this command are found here: http://www.windows-commandline.com/2009/01/find-windows-os-version-from-command.html
I get the following error compiling with make (I have cygwin.dll)
*** Couldn't reserve space for cygwin's heap (0x150000) in child, cygheap, Win32 error 0
0 [main] make 4336 sync_with_child: child 2968(0x120) died before initialization with status code 0x1
308 [main] make 4336 sync_with_child: *** child state waiting for longjmp
How could it be solved?
Thanks
I just ran into this problem and was advised to rebase the msys-1.0.dll which was causing the problem.
Specifically, I used the ReBase.exe tool:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64\ReBase.Exe
which is part of v7.1 (and perhaps other versions) of Microsoft's platform sdk available here.
take a backup of the dll, and then try this command line inside the platform sdk command prompt:
rebase -b 0x30000000 /path/to/msys-1.0.dll
this solved the issue for me.
for interest, my recommended virtual memory settings were set at around 3GB, and the actual allocated virtual memory was at 6GB.
Reboot your system:
Most users complaining about this problem reported it goes away after a reboot. If you are using Windows 7, check the message from BerndP in this thread, it has some tips related to adjusting Virtual Memory settings on Windows.
Might be some software interfering with Cygwin:
This post brings an interesting discussion of random problems with Cygwin. The BLODA list presents a list of applications that are known to cause strange failures and problems in Cygwin.
EDIT:
Windows 8 has not been officially released, so don't expect Cygwin to work on it.
Cygwin can be expected to run on all modern 32 bit versions of Windows This includes, as of the time of writing this, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, as well as the WOW64 32 bit environment on released 64 bit versions of Windows (XP/2003/Vista/2008/7/2008 R2).
I am working with eclipse and am using MinGW + Yagarto on Windows 8. Restarting did nothing.
I solved the issue by expanding my virtual memory, which was originally set to 896Mb and is not at 3000Mb and working fine.
This problem can be resolved by changing the compatibility mode of gcc.exe (or whatever called by make) into Windows Xp (in Properties->compatibility)
However, the script must be executed as administrator to avoid multiple confirmations when calling gcc.exe
I'm making a program called Pwn16. It allows 16-bit applications to run on 64-bit systems by emulating an Intel 8086/Pentium processor and a DOS/Win3.x/Win98 system. Pwn16 uses a small loader program that detects when Windows gives the "not 16-bit compatible" messages (including the one from CMD) and when it notices said message(s) being summoned, it will close it and instead automatically launch Pwn16.
Are there any libraries that will let me "capture" these messages and do something else in place of the errors? I'm making most of this in VB6, so any code that can do this will also help. I have the emulation and GUI down, I just need to get this loader done to finish it.
Messages I need to capture:
"The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher."
"Unsupported 16-Bit Application: The program or feature '(file)' cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available."
"This is not a valid Win32 application."
"The (file) application cannot be run in Win32 mode."
Thanks.
As far as I know, neither Explorer nor cmd.exe check the validity of the executable file in advance. Instead, they call CreateProcess and, if it fails, look at the error code returned.
So, if you hook calls to CreateProcess (or perhaps the underlying native API) you should be able to capture the error code being returned to Explorer/cmd.exe/whatever and do your thing instead.
I don't think capturing the message being presented to the user is going to be helpful. Quite apart from the inefficiency involved in examining every dialog box, and every piece of text written to every console, to see whether it contains the message you're looking for, how would you then identify which file the user was trying to run?