@georgel
1. Where did you get AWEUTIL 1.36?
2. Can you please post the source code to DOS32AWE?

I can help you with the first one. Usually it is located within the AWE64 driver CD but it would require an installation on a Windows 9x operating system in order to extract the files used for MS-DOS mode.

I uploaded the utility in a ZIP file to make life easier.

Gmlb256 wrote on 2022-07-01, 14:49:

I can help you with the first one. Usually it is located within the AWE64 driver CD but it would require an installation within a Windows 9x operating system in order to extract the files used for MS-DOS mode.

I uploaded the utility in a ZIP file to make life easier.

Many thanks! I could not find that version on the AWE64 driver CD I used. It only came with 1.35. Perhaps you have a newer version.
If georgel fails to deliver the source code within 24 hours I'm afraid I will have to disassemble his utility and post the assembly on GitHub. I've worked with refactoring parts of DOS32A to work with NASM instead of TASM in the past, so I'm not going to find much difficulty mapping what was written my Narech and what is his original modification. It only takes time to tell the two apart. If only DOS32A was under a strong copyleft license like GPLv2 or v3, this wouldn't be necessary.

Time's up. Enjoy! https://github.com/grepwood/dos32awe

With OP's permission: Re: DOS32AWE - DOS/4G compatible DOS Extender with Sound Blaster AWEUTIL MIDI synthesizer support for Protected mode,V
Archived: https://archive.ph/Rf7ob

Does anyone still have a version that doesn't check for memory managers? I want to test it with Mega-EM and protected mode games. According to Mega-EM NMI is not functioning and only works in real mode games.

Rawit wrote on 2022-07-14, 13:39:

Does anyone still have a version that doesn't check for memory managers? I want to test it with Mega-EM and protected mode games. According to Mega-EM NMI is not functioning and only works in real mode games.

No, but you can DIY now since DOS32AWE's source code is kind of up there. It is in fact based on DOS32A 9.1.2, so you should have no problem finding which part of DOS32A does that and putting your changes in a fork of DOS32AWE. Most of the source should be basically the same. I haven't gotten around to rename all the function names dropped by IDA

moog wrote on 2022-07-17, 22:35:

No, but you can DIY now since DOS32AWE's source code is kind of up there. It is in fact based on DOS32A 9.1.2, so you should have no problem finding which part of DOS32A does that and putting your changes in a fork of DOS32AWE. Most of the source should be basically the same. I haven't gotten around to rename all the function names dropped by IDA

Calling "source code" this mere automated disassembly output made me laugh because this is brutal fundamental lack of knowledge 😉 You claimed to be a license admirer but judging from your level of competence I doubt you had a license for a relatively expensive IDA sowtware you used 😉 Knowing how to open a file in IDA is not even a first step in reversing! Misleading others to deal with the undone hard work is deceptive. Can you even assemble back what you posted regardless you don't understand it at all? No. Your 24hrs ultimatum was also ridiculous 😉 What would you do had you had the source when it is not up to your level?

georgel wrote on 2022-07-21, 21:33:

Calling "source code" this mere automated disassembly output made me laugh because this is brutal fundamental lack of knowledge 😉 You claimed to be a license admirer but judging from your level of competence I doubt you had a license for a relatively expensive IDA sowtware you used 😉 Knowing how to open a file in IDA is not even a first step in reversing! Misleading others to deal with the undone hard work is deceptive. Can you even assemble back what you posted regardless you don't understand it at all? No. Your 24hrs ultimatum was also ridiculous 😉 What would you do had you had the source when it is not up to your level?

dude just stop

georgel wrote on 2022-07-21, 21:33:

moog wrote on 2022-07-17, 22:35:

No, but you can DIY now since DOS32AWE's source code is kind of up there. It is in fact based on DOS32A 9.1.2, so you should have no problem finding which part of DOS32A does that and putting your changes in a fork of DOS32AWE. Most of the source should be basically the same. I haven't gotten around to rename all the function names dropped by IDA

Calling "source code" this mere automated disassembly output made me laugh because this is brutal fundamental lack of knowledge 😉 You claimed to be a license admirer but judging from your level of competence I doubt you had a license for a relatively expensive IDA sowtware you used 😉 Knowing how to open a file in IDA is not even a first step in reversing! Misleading others to deal with the undone hard work is deceptive. Can you even assemble back what you posted regardless you don't understand it at all? No. Your 24hrs ultimatum was also ridiculous 😉 What would you do had you had the source when it is not up to your level?

You can always be the better person in this non-issue and post the actual source code 😉
But if not, well,

Why be good at all with you , impudent dude, that had sent me an ultimatum to publish the source within 24 hrs? You deserve not source but kick.

georgel wrote on 2022-07-22, 10:35:

Why be good at all with you , impudent dude, that had sent me an ultimatum to publish the source within 24 hrs? You deserve not source but kick.

Because you will prove you are the better person. If you go through my posts, you will see there was no ultimatum. I have asked you politely to post the source code - a request which you have completely ghosted. Since you have shown no initiative to oblige, I have decided to give you enough time until I take matters into my own hands.

As for your remarks on my use of IDA, you realize I only needed the freeware version to do this?

rasz_pl wrote on 2022-07-22, 00:37:

georgel wrote on 2022-07-21, 21:33:

Calling "source code" this mere automated disassembly output made me laugh because this is brutal fundamental lack of knowledge 😉 You claimed to be a license admirer but judging from your level of competence I doubt you had a license for a relatively expensive IDA sowtware you used 😉 Knowing how to open a file in IDA is not even a first step in reversing! Misleading others to deal with the undone hard work is deceptive. Can you even assemble back what you posted regardless you don't understand it at all? No. Your 24hrs ultimatum was also ridiculous 😉 What would you do had you had the source when it is not up to your level?

dude just stop

In this case, georgel is correct. A proper disassembly (and I am still not calling it "source code") should look more like this: https://pastebin.com/3JyJ3ZsJ . Note that this disassembly is meant to be compared to the official DOS32A source code. It is not polished into a form to be reassemblable, in contrary, the use of the IDA selector feature to treat segment number 8 as selector for the kernel segments makes both the real-mode base address (1006) and the protected mode selector number (0008) being displayed as "seg KERNEL" (which is readable, but how should the assembler know what number to assemble?), and also allow IDA to correctly trace the flow, whether the processor is currently in real mode or protected mode (both segments of DOS32A, the KERNEL and the CLIENT contain mixed protected mode and real-mode code!).

The disassembly is still kind-of ugly, because DOS32A overlays initialization code with runtime variables, and IDA doesn't provide any usable means to cope with that. It is good enough to show the difference between "I just loaded the file into IDA and used the 'Create ASM file...' command" compared to "I made sure all code is disassembled as code and all data is disassembled as data; by the way, I used the public source code of DOS32A to name all the functions".

The proper way to create a rebuildable DOS32AWE is to identify all differences (search for DOS32AWE in the pastebin to find all differences I noticed), and port them into the official DOS32A sources, and build it with the build system provided by the older DOS32A sources, as is indicated on the DOS32A web site / FAQ. It should be possible to rebuild DOS32AWE and perform a binary diff to check for completeness.

Have you guys also tried Ghidra for disassembling? I'm not sure how well it compares with IDA, since I've never used IDA. I have played with Ghidra's disassembler a bit, and it seems fairly powerful. Perhaps it would do a better job with disassembling this particular code?

Or, crazy idea, maybe georgel can just be a good sport and release the sources to the modifications he made on code that was already open-source? What better way to show off one's coding skills? Or maybe he has some embarrassing things to hide? 😉

I know both IDA and Ghidra. Ghidra definitely has is place and has a lot of unique selling points, especially if you are constrained to use free software. One of the major selling points of Ghidra is its decompiler, which works on a lot of platforms. In the case of DOS32A, though, you can immediately discard any kind of decompiler that tries to reverse engineer a C source code representation of the application. DOS32A has been written in assembly code violating a lot of conventions that C compilers assume. Thus the code of DOS32A is plainly unrepresentable in standard C code. Any decompiler, no matter whether you sold your kidney to obtain a Hex-Rays license or just use free Ghidra will produce output that is unusable in most places.

As for reverse engineering DOS32A, only disassembly is possible, Ghidra loses its selling point of having a decompiler. IDA 5.0 Freeware edition has a quite good x86 disassembler. It might be that Ghidra is up to par with it, but I am so used to IDA since more than 20 years that I did not try to learn Ghidra for plain disassembler use. My limited attempts at using ghidra as disassembler didn't go too well, because I felt that I do not have the freedown to tailor the disassembly in the same way as I can do with IDA (that's the I in IDA for "interactive dis-assembler). While it might be possible that Ghidra has a better model of overlaid address spaces that would allow to map variables over the initialization code, I wouldn't expect Ghidra to excel at 16-bit code.

The main point that discriminates my disassembly from the "source code" posted by moog is that the disassembly I posted got the code/data distinction correct (due to manual intervention in IDA) whereas it is wrong in many places in moog's disassembly (it's the result of IDA's auto-analysis). Possibly, Ghidra could have better heuristics or flow tracing here, but I highly doubt the flow tracer of Ghidra actually does a good job on non-conventional 16-bit x86 code that mixes real-mode and protect-mode code, as this kind of code typically no longer in focus of today's reverse engineering.

mkarcher wrote on 2022-07-26, 17:40:

Possibly, Ghidra could have better heuristics or flow tracing here, but I highly doubt the flow tracer of Ghidra actually does a good job on non-conventional 16-bit x86 code that mixes real-mode and protect-mode code, as this kind of code typically no longer in focus of today's reverse engineering.

That's a good point. The executable I tried to disassemble with Ghidra, VSB, is a mix of 16-bit and 32-bit code, and Ghidra seemed to have difficulty with that in particular.

I am not impressed by your reversing skills. But I've mentioned that reversing of the real mode AWEUTIL will be very useful in regard to its obscure problem when dealing with large SBKs. There you won't have to deal with peculiarities of IA32...Only 8086 instruction set is used in it. You should be able to use even Sourcerer 😉

interesting flaming. a human will never write assembly code with unreadable labels. 🤣
But I'm more interested in the source code.

georgel wrote on 2022-07-31, 12:19:

I am not impressed by your reversing skills. But I've mentioned that reversing of the real mode AWEUTIL will be very useful in regard to its obscure problem when dealing with large SBKs. There you won't have to deal with peculiarities of IA32...Only 8086 instruction set is used in it. You should be able to use even Sourcerer 😉

Thank you very much for this hint!
I wasn't trying to impress anyone. I'm sure that there's a lot I could learn, but this very basic use of freeware IDA is enough for me to do something useful. That certainly has been the case in the past.

georgel wrote on 2022-07-31, 12:19:

I am not impressed by your reversing skills.

You don't need to be impressed. Anyway, here is a repository with usable source code: https://github.com/karcherm/dos32awe

I know some people are annoyed that recent versions of DOS32AWE refuse to work with EMM386. The code enabling this behaviour is seperated in a dedicated commit, and could easily be reverted, but I advise you to keep in the check for "running with DPMI host", so you might increase the "maximum allowed mode" constant from 1 (HIMEM loaded) to 2 (EMM386 loaded), but mode 3 (using external DPMI server) should stay forbidden, as the NMI forwarding logic is part of the DOS32A-integrated DPMI server, so it won't be enabled if an external DPMI server is used.

mkarcher wrote on 2022-08-14, 17:33:

georgel wrote on 2022-07-31, 12:19:

I am not impressed by your reversing skills.

You don't need to be impressed. Anyway, here is a repository with usable source code: https://github.com/karcherm/dos32awe

I know some people are annoyed that recent versions of DOS32AWE refuse to work with EMM386. The code enabling this behaviour is seperated in a dedicated commit, and could easily be reverted, but I advise you to keep in the check for "running with DPMI host", so you might increase the "maximum allowed mode" constant from 1 (HIMEM loaded) to 2 (EMM386 loaded), but mode 3 (using external DPMI server) should stay forbidden, as the NMI forwarding logic is part of the DOS32A-integrated DPMI server, so it won't be enabled if an external DPMI server is used.

Your advice is completely incompetent because you can't figure out the reason this check was implemented. I doubt all of you would be able to improve anything in DOS32AWE because you were unable to reach yourself the solution I created. You had the only option - to reverse DOS32AWE to partially figure out what was going on in that simple code of mine .