Recent Posts

Pages: [1] 2 3 ... 10
1
The Colosseum / Re: Kaspersky
« Last post by hutch-- on Today at 09:55:29 AM »
Poverty is a great teacher, you learn very quickly what is worth having and what does not matter. Over the span of a lifetime most people have variable fortunes, sometimes you have money to waste, other times you risk going hungry but if you learn from the lean times, you don't waste the excess in better times and you get a lot better at avoiding the next lean time. One of the great lessons to learn is never owe money, debt burdening is the current technique that replaces serfdom and the trick is to do whatever you need to escape any form of debt, then they can go PHUK themselves as they no longer have that form of control over you.
2
The Colosseum / Re: Great news...
« Last post by hutch-- on Today at 09:48:05 AM »
Van,

Sounds like a smart kid, a lack of herd instinct is a true virtue. I would not encourage him to go to West New Guinea having watched a few docos on flying there, some of those airstrips on mountain tops would be hard for a helicopter pilot to land on let alone a conventional aircraft.
3
The Soap Box / Re: What happened this weekend
« Last post by FORTRANS on Today at 09:29:53 AM »
Hi Alex,

   Thank you for sharing the story.  I put on a smile for that one.

Cheers

Steve N.
4
UASM Assembler Development / Re: UASM 2.46 Release
« Last post by johnsa on Today at 09:24:51 AM »
Packages are updated, oo2.asm is fixed and the 32bit COM call issue should be fixed.
5
MasmBasic & the RichMasm IDE / GetFolders
« Last post by clamicun on Today at 09:08:58 AM »
Hi JJ,
I bought me a new machine ... Windows 10 Home 64b
By coincidence I used an old prog which contains:

Let esi="C:\"
GetFolders esi   
mov .....

The prog goes down badly.

Works fine on drive D and E which are much smaller.

Any idea ?
6
UASM Assembler Development / Re: UASM 2.46 Release
« Last post by johnsa on Today at 09:07:59 AM »
You are right about oo2.asm, I must have forgot to update that sample after adding the return type to CVIRTUAL. I've updated it myside so it's correct and will be in the next package update.

_INVOKE and _I are designed to bypass the VTABLE altogether, their syntax is as follows:
Code: [Select]
_INVOKE MACRO className : REQ, method : REQ, objPtr : REQ, args : VARARG
_I MACRO className : REQ, method : REQ, objPtr : REQ, args : VARARG

_INVOKE would be for normal outer calls, and _I would be used inline.

Code: [Select]
_INVOKE MyClass, MyMethod, pObj, ......

The _V equivalents access the object through the vtable and have slightly different syntax:

Code: [Select]
_VINVOKE MACRO pInterface : REQ, Interface : REQ, Function : REQ, args : VARARG
_V MACRO pInterface : REQ, Interface : REQ, Function : REQ, args : VARARG

_VINVOKE pObj, MyClass, MyMethod, ....


I didn't include any references to VCOM or VCOMINVOKE in the documents as I didn't think anyone would call those directly / they are available.. but they're sort of "internal" to implement the COMINTERFACE and method invocation against it.

They're definitions are:

Code: [Select]
_VCOMINVOKE MACRO pInterface : REQ, Interface : REQ, Function : REQ, args : VARARG
_VCOM MACRO pInterface : REQ, Interface : REQ, Function : REQ, args : VARARG

So basically the same as the vtable based OO functions (VINVOKE and V) but they perform a double indirection.

I will update the packages shortly with fixes.
7
The Colosseum / Re: Great news...
« Last post by K_F on Today at 09:07:47 AM »
 :t
I think he's forming a chip off the old block..  :redface:

On numerous occasions in lectures they've been given options and have to explain their choices.
He says that when he explains his choices everyone else looks at him if he's nutz... but the lecturers say he is correct.  :shock:

I've always encouraged the kids to trust their instincts, no matter what the world thinks.. so maybe this is working for the greater good.
 :idea:


8
The Workshop / BCryptGenRandom
« Last post by jj2007 on Today at 08:16:37 AM »
Rumours say it's fast and good quality...

include \masm32\MasmBasic\MasmBasic.inc         ; download
  Init
  randbytes=1000000
  Let edi=New$(randbytes)
  Dll "BCrypt"
  Declare void BCryptGenRandom, 4
  BCryptGenRandom(0, edi, randbytes, 2)
  For_ ecx=0 To 29
        Print Str$("%i\n", dword ptr [edi+4*ecx])
  Next
  Inkey "hit any key"
EndOfCode
9
64 Bit Assembler / Re: 64 bit macro glossary
« Last post by markallyn on Today at 08:11:20 AM »
JJ-

Thanks for the info.  I guess that explains why the two have a similar look and feel.  I liked OLLY a lot and was disappointed to discover that Oleh Yuschuk had not made it 64 bits. 
x64dbg is definitely bloated but it is quite usable.  I settled in on a few of its many "bloats" and ignore the rest.  As you say, it works.

Mark
10
64 Bit Assembler / Re: 64 bit macro glossary
« Last post by jj2007 on Today at 08:06:00 AM »
x64dbg was somehow a "knockoff" of someone else's work

Somebody else is Oleh Yuschuk, and his baby is called OllyDbg.
Both Olly and X64Dbg can be set as just-in-time debuggers, meaning that when a program crashes, Olly (32-bit) or X64Dbg (64-bit) jump in and point you straight at the problem. Extremely handy in case of unknown problems (and yes, X64 is bloated, but it works).

In case of known problems, Integrated debugging is better.

I believe it is because of your care and example

Yes, Hutch has become old and wise. Nowadays it's almost incorrect to call him a grumpy old bastard ;)
Pages: [1] 2 3 ... 10