In MQL5 there is always room for an exploit ! ;) - page 2

New comment
 
sergeev:

And so there is question number one.

How do you import functions from 32 bit dlls like user32.dll etc. into a 64 application? Or are there copies for them in the system with that name and an OOP space is created ?

Well for a start, x64 systems have emulated launch of x86 programs. The question is how to run x64 programs in x86?
 
Urain:
Well, for a start, x64 systems have emulated launch of x86 programs. The question is how to run x64 programs in x86?

Maybe the question is not about the terminal at all but about some tricky compilation of these very DLLs?

The DLL's are powered by the Windows API, e.g. user32, kernel32, winmm, wininet in the 32/64 bit terminal.

The solution of the problem seems to lie somewhere else.

 
Urain:
The question is how to run x64 programs in x86?
It definitely won't work. x86 processor can't execute 64-bit instructions.
sergeev:

May be the question is not about the terminal at all, but about some tricky compilation of these very DLLs?

For example, user32, kernel32, winmm, wininet work in 32/64 bit terminal.

The solution to this problem seems to lie elsewhere.

So, theoretically, you may make 32-bit DLLs work there and there.

Perhaps it's time to call the developers.

Perhaps there are more cunning ways of compilation // I stopped working with a 32-bit DLL compiled in a "naive" way on x64. Anyway, there are precedents that "exist" (c).

For example, user32, kernel32, winmm, wininet in the 32/64 bit terminal.

 
MetaDriver:

So do it in that analogy... no big deal!... :-))

I'll have a look. ;)

//+------------------------------------------------------------------+
class Cdouble
{
public:
        double                  v;
        void    operator=       (double d) {v=d;}
};
//+------------------------------------------------------------------+
class C1Xdouble
{
        Cdouble                 v[];
public:
        
                                C1Xdouble() {}
                                C1Xdouble(int s) {ArrayResize(v,s);}
                               ~C1Xdouble(){ ArrayFree(v);}
        double operator[]       (int x) {return(v[x].v);}
        Cdouble *operator[]    (long x){return(GetPointer(v[(int)x]));}
        int                     Resize(int s){ return(ArrayResize(v,s));}
};
//+------------------------------------------------------------------+
class C2Xdouble
{
        C1Xdouble               v[];
public:
                                C2Xdouble() {}
                                C2Xdouble(int s1,int s2);
                               ~C2Xdouble(){ ArrayFree(v);}
        C1Xdouble *operator[]   (int x) { return(GetPointer(v[x]));}
};
C2Xdouble::C2Xdouble(int s1,int s2)
{
        ArrayResize(v,s1);
        for(int i=0; i<s1; i++) v[i].Resize(s2);
}
//+------------------------------------------------------------------+
The simplest way to apply it to your case.
 
Yurich:
The simplest version for your case.

Well, for the simplest case, credit. "I'm writing you down" :)

From memory, but not sparingly, by comparison. 

    C2Xdouble  X(1000,1000);
    Print("X(100,100).SizeOF() = ",X.SizeOf()); 
// добавил в ваши классы вычисление размера
-----
    C2DMagicArray  MA(1000,1000);
    Print("MA(100,100).SizeOF() = ",sizeof(MA)+MA.SizeOf()); 
// это мой. у меня MA.SizeOf() возвращает только размер чистого буфера, поэтому по честному добавил размер класса. :)

result:

2012.05.23 12:59:05     CXDouble (AUDNZD,M1)    MA(100,100).SizeOF() = 4000112
2012.05.23 12:59:05     CXDouble (AUDNZD,M1)    X(100,100).SizeOF() = 24068068

The difference is 6 times. Taking into account that I have a float buffer - 3 times. // You also have an implicit memory robbery - your system table of class descriptors (in this example) is 1000*1000+1000, while mine is 1 (!).

Speed is almost the same.

Will you be shrinking? ;)

--

I lied, your subclasses are all static, so the implicit robbery is a bit exaggerated. Scratch that. :)

 
MetaDriver:

Perhaps it's time to call the developers.
Briefly.
The system library functions for x86 (32 bit) processes have a special wrapper through which they are passed to x64, executed and returned back to x86.
 
mql5:
Briefly.
System library functions for x86 (32 bit) processes have a special wrapper, through which they are transferred to x64, executed and returned back to x86.

Thank you for the information.

Can you tell me how to do the same on your own? Just a link (if available).

 
MetaDriver:


Will you be shrinking? ;)

No, I use one-dimensional arrays whenever possible.
 
Isn't #ifdef the normal solution to the problem?
 
Yurich:
No, I use one-dimensional arrays whenever possible.

OK. Optimisation issues are secondary in this case. The feat is defended anyway.

--

I can offer you the following problem.

Array has arbitrary dimensionality (let's limit it to ^16 for clarity).

Dimensionality is set at creation by number of parameters, as for usual arrays.

XXArray  xx2(5,7),  xx5(12,12,16,16,8);

Should work for all dimensions indexers ( A[i][j][k][n][m]....)

Just for sport and brain training. :)
123456789
New comment