News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Try VS debugger and a RadAsm addin to start it

Started by minor28, December 13, 2016, 08:32:44 AM

Previous topic - Next topic

minor28

I use to write my assembler code with RadAsm IDE and debugg with Visual Studio.
I start debugging with a RadAsm addin named VSRun.dll.
Now I have acquired Windows 10 64-bit and installed Visual Studio 2015 Community.
The old addin doesn't work and VS behaves differently.

The addin is rewritten and I have also written a syntax highlighting VS extention.

For me it works without errors. If someone want to try, please do, but I will not
provide any support
minor28.divdev.se/Debugging.zip


AssemblyChallenge

Thank you. Did you try x64dbg? Is getting better and better, free, portable and several gigabytes smaller than VS.

jj2007

Quote from: AssemblyChallenge on December 14, 2016, 01:33:47 AMDid you try x64dbg?

"A familiar, yet new interface" - I wonder if Oleh Yuschuk had a role in this ::)

Here is an interesting blog post on x64.

Re VS Community, I also installed it, and can only say "hands off". Never ever seen such a slow and bloated crap.

hutch--

With thanks to sinsi, I used ArkDasm when I was doing the very level research for Win 64 and found it fast and reliable doing work like this. I learnt debuggers with Microsoft "Codeview" which was the bees knees in 1990 and have rarely like any debugger since. Around 2000 SoftIce was a very good tool but the folks who got the most use out of it were the crackers, even though it was designed for debugging drivers.

I have rarely ever needed to do much more than point results at a console or check something inline with a MessageBox which has a happy characteristic of stopping the executable where you want it and even if the app crashes directly after it, its a simple and fast way to find out what is happening at a specific point in an application.


TWell

#5
arkDasm users, read this

EDIT: BugDbg use QT4 and is 13 Mb total size.

jj2007

Quote from: TWell on December 14, 2016, 07:54:06 PM
arkDasm users, read this

Quoteyou will find a few things on Qt5 giving you hard times. For example, deploying a hello world application in Windows will have an (unacceptable) size of around 30MB !

Oops, I thought the minimum size for a QT hello world proggie was only around 8 MB... so they are still improving QT?

GoneFishing

Just compiled helloworld proggie with Qt5.7 on Linux  . Dynamic linking to Qt libraries .
debug version size     = 26358
stripped version size  = 6304
#include <iostream>

int main(int argc, char *argv[])
{
    std::cout<<"Hello, World !" << std::endl;
    return 0;
}


Qt is getting more  and more popular .

jj2007

Now try the same with static linking. Or post the exe together with the required libraries here.

GoneFishing

There's no sense in attaching compiled linux binaries here . Qt is cross-platform  and I assume that posting source code will be enough . When you attach your executable you don't include all system32/64  DLLs in your archive, right ? BTW how much do all those DLLs weight ? 2 or 3 Gb ?  Imagine that you  statically  link your MasmBasic  :biggrin: 

jj2007

The point is that a "standalone" Masm32 exe weighs in at 1536 bytes; a MasmBasic exe at around 24kBytes (shame on me :icon_redface:).

The definition of "standalone" is: it works without additional libraries that a user would have to download and install.

94 bytes -> 1536:
include \masm32\include\masm32rt.inc
.code
start:
  inkey "Hello World"
  exit
end start


84 bytes -> 25088:
include \masm32\include\masm32rt.inc
.code
start:
  inkey "Hello World"
  exit
end start


Test the attachments. They will run.

GoneFishing

I'll not argue about virtues of MASM32 there's  no doubt about it ... but let's have a look at nowadays' CPP  world : big fat frameworks meant to be user friendly and rich in functionality , able to host large projects . Recently I worked much compiling different complicated CPP projects and it was very comfortable to navigate the source/include tree with Qt Creator , my current IDE of choice.  The other side of such big frameworks is that they may  slow down app performance .       

jj2007

#12
Quote from: GoneFishing on December 15, 2016, 12:19:13 AMThe other side of such big frameworks is that they may  slow down app performance.

I have installed VS community. Big mistake. Never seen such an incredibly slow piece of crap.

Besides, I understand the desire to be cross platform etc. Truth is, the idea is good but the result is crap. QT seems popular on Linux, probably because they don't have any equivalent to Win32 GUI apps. But over 10MB for a statically linked hello world proggie? Ridiculous. Asking the user to download and install gigabytes of libraries, for dynamic linking? Equally ridiculous.

C/C++ claim to be "professional" cross platform languages. But most of the bright code examples that you can find on SOF work only on a specific compiler, let alone between OSes. What I find most impressing is that a Micros**t hello world "project" designed for, say, VS 2010, will often crash when you try to load it in, say, VS 2015. It is such an ugly mess that in such moments I feel morally obliged to send a cheque to Mr. Steve Hutchesson, the genius who designed Masm32. Load the over 17 years old \Masm32\examples\exampl01\generic\generic.asm in qEditor, build it with one mouse click, and you are done (or open it in RichMasm and hit F6).

Masm32 works.

In contrast, loading a console proggie in VS community takes over one-hundred seconds, on an Intel i5. When this ultimate achievement of the Richmond "geniuses" is finally "responsive", i.e. ready to interact with the user, it greets me with a MessageBox saying
Quote"An exception has been encountered. This may be caused by an extension.

You can get more information by examining the file 'C:\Users\Jochen\AppData\Roaming\Microsoft\VisualStudio\14.0\ActivityLog.xml'."

Needless to say that I never installed extensions for this Micros**t joke, and that studying >72kB of xml shyte is just a waste of time.

The problem with these packages is that the more people are involved, the bigger they grow, and at a certain point, they simply lose control over their pile of shyte. And there is no manager who would dare to impose restrictions - more features, more crap, more bugs, too slow? who cares, the hardware will become faster anyway... etc.

You can see the result every day when you switch on your machine, and you see heavy activity of "services" which are downloading gigabytes of so-called "updates". And this is WINDOWS, M$'s flagship product, with a Billion users or so world-wide. M$ is NOT allowed to make mistakes with this product, right? So hundreds or thousands of really brofessional cpp brogrammers are desperately chasing Windows bugs all day and night long in Richmond, Seattle. No time to care for VS "community", if there is a community, they can do the bug chasing, right?

I will start taking M$ seriously the day when after Patch Tuesday I discover in C:\Windows a RichEd20.dll that has no serious bugs.

But they have other priorities in Richmond (source):
QuoteThe final critical bulletin in the Dec. Patch Tuesday release is MS16-148, which resolves 16 vulnerabilities in Microsoft Office

I'd love to see a Microsoft press release saying that on December 15, 2016, 16 incompetent coders got fired 8)

One more:
QuoteThis security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB16-39:

CVE-2016-7867, CVE-2016-7868, CVE-2016-7869, CVE-2016-7870, CVE-2016-7871, CVE-2016-7872, CVE-2016-7873, CVE-2016-7874, CVE-2016-7875, CVE-2016-7876, CVE-2016-7877, CVE-2016-7878, CVE-2016-7879, CVE-2016-7880, CVE-2016-7881, CVE-2016-7890, CVE-2016-7892

Sounds ridiculous that one tiny piece of software is so "vulnerable" that it needs "security" updates almost on a weekly basis? It is indeed ridiculous, but behind these "updates" is a business model: Many commercial websites run a hidden flash player that reports user activities back to Adobe. And apparently, they are refining that software continuously to better serve the needs of Ama*on and others.

powershadow

Hi, minor28
Could you explain how to enable asm highlight in Visual Studio? I successfully install MasmPackage.vsix to VS 2015. "Masm Language" appears in "Options>Text Editor", but no highlight on *.asm files. May be I need add some info to "Options>Text Editor>File Extension"?
Thanks.

hutch--

 :biggrin:

> It is such an ugly mess that in such moments I feel morally obliged to send a cheque to Mr. Steve Hutchesson, the genius who designed Masm32

I would accept the cheque but the money would be far better spend on a few good bottles of vino that you could enjoy in good company. Being a true assembler purist I only drink pure malt but I have such a good collection that I could get most of my suburb drunk if I was willing to waste it. Our friends from the Russian republic can be excused for drinking rocket fuel (wodka) and from memory those of truly stout construction in the US drink "white lightning" but I think NASA want as much as possible to fuel their next mission.

Truly VS is a mess, you should see the professional version at 15 gig download, the biggest pile of CHYTE I have ever seen and I only wanted the MASM and supporting binaries.