60 replies to this topic

[Wonko the Sane]

Yep, I know how to spawn a separate window , I am using this right now:

start /min devio --dll=proxy.dll;dllopen shm:test_proxy C:\appoggio\scrambled\vmdkisotest\Core-current.isi
imdisk -a -t proxy -o shm -o cd -f test_proxy -m Z:

Which is fine for my personal use, but I was thinking more about the "end user" and the possible need to actually get the result of the command, like the initial part of the output, i.e. it would be nice to get this:

 

File to open: C:\appoggio\scrambled\vmdkisotest\Core-current.isi
TLibvmdk OK
size: 8286208
Successfully opened 'C:\appoggio\scrambled\vmdkisotest\Core-current.isi'.
Read request - size:1536 offset:0
Image size used: 8286208 bytes.
Read request - size:512 offset:0
No master boot record detected. Using entire image.
Total size: 8286208 bytes. Using 8286208 bytes from offset 0.
Required alignment: 1 bytes.
Buffer size: 2097152 bytes.
Shared memory operation.
Waiting for connection on object test_proxy. Press Ctrl+C to cancel.
Creating device...
Connection on object test_proxy.
Read request - size:512 offset:0
Created device 0: Z: -> test_proxy
Notifying applications...
Done.

 

and nothing else, at least to me (and I presume to the end user as well) an infinite number of:

 

Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0
Read request - size:0 offset:0

 

are pretty much meaningless....

 

Wonko

[Olof Lagerkvist]

infinite number of:

 

are pretty much meaningless....

 

 

No, actually that shows why it is good to have some messages from devio while running. Those "Read request - size:0 offset:0" you apparently see there is not something that are expected, for instance. When working correctly, nothing should be displayed after ImDisk has connected. If some error occurs or something otherwise unexpected, that could be good to know for various reasons. For instance, to come back to the programmer with.

 

It something does not seem to work properly with the virtual disk, I usually check the devio window and see if there are any messages after the "connected" message. If there are, something might have gone wrong somewhere.

[erwan.l]

and nothing else, at least to me (and I presume to the end user as well) an infinite number of:

 

are pretty much meaningless....

 

Wonko

 

i'll see if i can put an option to hide/disable the debugging on my end.

[Wonko the Sane]

No, actually that shows why it is good to have some messages from devio while running. Those "Read request - size:0 offset:0" you apparently see there is not something that are expected, for instance. When working correctly, nothing should be displayed after ImDisk has connected. If some error occurs or something otherwise unexpected, that could be good to know for various reasons. For instance, to come back to the programmer with.

 

It something does not seem to work properly with the virtual disk, I usually check the devio window and see if there are any messages after the "connected" message. If there are, something might have gone wrong somewhere.

Sure , but again that pertains to the "developer" or maybe to the "advanced" user, not to the "final" one.

 

Right now, if I can call myself "advanced" , all I see is the IMDISK Z: drive working nicely (in the sense that I can read files in it) and a load of meaningless (to me) messages, and surely they would only confuse the "end" user.

 

As a side-side note (and not really relevant), there are IMHO a few characters that should NEVER be in the console output of a command, like redirection symbols as in:

Created device 0: Z: -> test_proxy 

 

as they represent a royal PITA if the output needs to be parsed.

 

Wonko

[Olof Lagerkvist]

Sure , but again that pertains to the "developer" or maybe to the "advanced" user, not to the "final" one.
 
Right now, if I can call myself "advanced" , all I see is the IMDISK Z: drive working nicely (in the sense that I can read files in it) and a load of meaningless (to me) messages, and surely they would only confuse the "end" user.

With all respect, but I would much more like to figure out where those messages come from and why and what to do about it, rather than just hiding them.
 

As a side-side note (and not really relevant), there are IMHO a few characters that should NEVER be in the console output of a command, like redirection symbols as in:
as they represent a royal PITA if the output needs to be parsed.

Well, I have a few scripts running in various places with for /f "delims=^>, token=2" like things to parse exactly that output, so there is no way I could change that now.

[Wonko the Sane]

I was thinking more about like a couple of switches :

no switch = No log except the initial part up to "Waiting for connection on object test_proxy. Press Ctrl+C to cancel."

-v Verbose (for the "advanced" users)

-vv Very Verbose (for the "developers")

 

Wonko

[Olof Lagerkvist]

I was thinking more about like a couple of switches :
no switch = No log except the initial part up to "Waiting for connection on object test_proxy. Press Ctrl+C to cancel."
-v Verbose (for the "advanced" users)
-vv Very Verbose (for the "developers")

Okay, I see how you mean. The problem is that devio.exe itself practically only displays the initial part up to "Waiting for connection...". After that it only shows error messages that the end user most probably need to care about somehow. Those messages are only fatal error messages where things have gone really wrong somehow.

 

Now, the request/size/offset messages you see do not come from within devio.exe and they would anyway not be affected by a command line switch. I would guess that they are printed directly to the console window by one of the loaded dll files and the question I ask myself or anyone else is, why, what for and do we really need to care about anything? Or are the messages just printed by mistake somewhere and would be easy to remove somehow? That's something left to investigate.

[erwan.l]

Okay, I see how you mean. The problem is that devio.exe itself practically only displays the initial part up to "Waiting for connection...". After that it only shows error messages that the end user most probably need to care about somehow. Those messages are only fatal error messages where things have gone really wrong somehow.

 

Now, the request/size/offset messages you see do not come from within devio.exe and they would anyway not be affected by a command line switch. I would guess that they are printed directly to the console window by one of the loaded dll files and the question I ask myself or anyone else is, why, what for and do we really need to care about anything? Or are the messages just printed by mistake somewhere and would be easy to remove somehow? That's something left to investigate.

 

I play guilty.

If you look in my source code (provided) you'll see that I output to the console some basic datas like length, offset, etc ...

Because the proxy is loaded by devio.exe, my console messages come thru devio console.

I am not sure if it was a predicted effet by Olof thus? And I am not sure if the devio switches can influence this (hide / show ?).

 

I see this debug is not very popular so i will hide it by default

Only with a specific switch (some ini file I guess...) will these be displayed.

Although I'd rather have devio control this.

[Wonko the Sane]

I play guilty.

Well, you CANNOT do that!

 

You either are (and optionally plead ) guilty, or you are innocent (unlikely but still possible ) but you cannot "play" either.

 

Wonko

[erwan.l]

new vmdk imdisk proxy here.

[Wonko the Sane]

new vmdk imdisk proxy here.

No worky.

Missing entry point FlsGetValue in KERNEL32.DLL.

Devio CRASH.

 

Wonko

[erwan.l]

No worky.

Missing entry point FlsGetValue in KERNEL32.DLL.

Devio CRASH.

 

Wonko

 

You meant TlsGetValue right?

If so, I dont understand : this import was already there in the previous proxy.dll ?

Plus, it is supported by XP clients.

 

I am lost.

The only difference being that I built it on windows 8.1 x64 but kept the same delphi version.

[Olof Lagerkvist]

I would guess that he indeed means FlsGetValue and not TlsGetValue. TlsGetValue (thread local storage) has been around since I guess the very first version of Windows NT so that should never be a problem. FlsGetValue (fiber local storage) was IIRC introduced in kernel 5.2.3790, that is Windows Server 2003. So, unavailable in XP and earlier.

[erwan.l]

I would guess that he indeed means FlsGetValue and not TlsGetValue. TlsGetValue (thread local storage) has been around since I guess the very first version of Windows NT so that should never be a problem. FlsGetValue (fiber local storage) was IIRC introduced in kernel 5.2.3790, that is Windows Server 2003. So, unavailable in XP and earlier.

 

 

ok found it, thanks @Olof for the tip..

 

@wonko : please discard the mscvr120.dll in the package.

I thought i had renamed a msvcr110.dll to msvcr120.dll but obviously made a mistake somewhere.

Will remove it from the zip file for now...

Will also update this topic and the other linked one.

 

@wonko : maybe you can attach your renamed msvcr dll here for future readers?

Attached Files

•  proxy_vmdk.zip   412.63KB   490 downloads

[Wonko the Sane]

Hint, I live in Florence, NOT Tlorence .

 

The dependency is in the libvmdk.dll, but seemingly it is not "triggered" by the previous version of proxy.dll.

 

BUT, making the nth frankensetup , the culprit is the actual msvcr120.dll (actually msvcr110.dll renamed) shipped in the package.

That one is version: 

11.0.50214.1 Microsoft® Visual Studio® 11 Beta Size:858.176 bytes

 

The one I used before AND THAT MAKES ALSO this build WORK is:

 11.0.51106.1 Microsoft® Visual Studio® 2012 Size: 875.472 bytes

 

DLL HELL anyone? :

 

 

Wonko

 

EDIT:

@erwan.l

Attached.

Attached Files

•  msvcr110renamedto120.zip   466.82KB   488 downloads

[Olof Lagerkvist]

For Visual Studio 2012 and 2013 there are two "Platform Toolsets" each. "Visual Studio 2012", "Visual Studio 2012 - Windows XP", "Visual Studio 2013" and "Visual Studio 2013 - Windows XP". The XP versions seem to disable a few things that are not XP compatible. But it could also happen that the code generated should be able to run together with some versions of msvcr110.dll and msvcr120.dll that are built specifically to be XP compatible. I am not sure about that though, but I wouldn't be surprised. DLL hell - yep.

[Wonko the Sane]

Ok, guys, this is starting going on my nerves  .

 

TIll now I believed that there was a dependency to the stupid msvcr120.dll in the version of libvmdk.dll shipped in erwan's package (20140421).

 

So I tried to setup the nth+1 frankensetup, using with erwan.l's proxy.dll  the libvmdk.dll shipped in Olof's package (20141030).

 

BUT the need for msvcr120.dll is still there, so I checked EVERYTHING with CFF explorer, and seemingly the issue is ALSO in zlib.dll, the one shipped in Olof's package (1.2.8 dated 30/04/2015) has NOT a dependency on msvcr120.dll, whilst the one shipped in erwan.l's package (also 1.2.8 but dated 21/07/2014) has it.

 

So.

erwan.l's proxy.dll (the 92.160 "reduced size" version)

Olof's libvmdk.dll

Olof's zlib.dll

work fine together without any need for msvcr120.dll (or for msvcr110.dll renamed).

 

The stupid *whatever* continues to send to the console the meaningless "Read request - size:0 offset:0" messages, however.

 

Wonko

[erwan.l]

On a more generic discussion, this is about statically linking versus dynamically linking (i usually go for the later).

 

While being loaded by libvmdk.dll, mscvr120.dll statically links against kernel32.dll

Since kernel32 xp sp2 is missing one specific API, it will create an error.

Quiet a shame when you consider this specific api is not actually called by libvmdk.dll

 

@Wonko : note that tools like cff (or any other dependency walker) will not show you the dynaminc links but only the static links.

If one uses the loadlibrary+getprocaddress api's to load an external function, it wont show.

 

So not seeing a specific dll in the imports list does not mean the dll is not needed...

And I am pretty sure libvmdk.dll will need zlib.dll unless there is a way in C++ to include zlib code in the main dll itself.

[Olof Lagerkvist]

Ok, guys, this is starting going on my nerves  .
 
TIll now I believed that there was a dependency to the stupid msvcr120.dll in the version of libvmdk.dll shipped in erwan's package (20140421).
 
So I tried to setup the nth+1 frankensetup, using with erwan.l's proxy.dll  the libvmdk.dll shipped in Olof's package (20141030).
 
BUT the need for msvcr120.dll is still there, so I checked EVERYTHING with CFF explorer, and seemingly the issue is ALSO in zlib.dll, the one shipped in Olof's package (1.2.8 dated 30/04/2015) has NOT a dependency on msvcr120.dll, whilst the one shipped in erwan.l's package (also 1.2.8 but dated 21/07/2014) has it.
 
So.
erwan.l's proxy.dll (the 92.160 "reduced size" version)
Olof's libvmdk.dll
Olof's zlib.dll
work fine together without any need for msvcr120.dll (or for msvcr110.dll renamed).

The zlib.dll sources are included in libvmdk package as well and normally built with same settings and dependencies as libvmdk.dll itself gets. So, when Erwan.I built libvmdk.dll with msvcr120.dll dependency, he also got a zlib.dll with the same dependency.
 

The stupid *whatever* continues to send to the console the meaningless "Read request - size:0 offset:0" messages, however.

That message comes from Erwan.I's proxy.dll.

[Wonko the Sane]

On a more generic discussion, this is about statically linking versus dynamically linking (i usually go for the later).

 

While being loaded by libvmdk.dll, mscvrxxx.dll statically links against kernel32.dll

Since kernel32 xp sp2 is missing one specific api, it will create an error.

Quiet a shame when you consider this specific api is not actually called by libvmdk.dll

No, the more generic discussion is about developers (and particularly very good ones, like I consider both yourself and Olof ) should pass ANYTHING they produce through Okham's Razor, and if a simpler way exists, use it instead of any more complex one.

 

Wonko

[Olof Lagerkvist]

@Wonko : note that tools like cff (or any other dependency walker) will not show you the dynaminc links.

Depends.exe show dynamic dependencies as well, but only when you run the application within depends.exe window. It shows * signs and yellow icons for things loaded dynamically and * signs with red icons when a dynamic dependency could not be resolved.

[erwan.l]

Depends.exe show dynamic dependencies as well, but only when you run the application within depends.exe window. It shows * signs and yellow icons for things loaded dynamically and * signs with red icons when a dynamic dependency could not be resolved.

 

Correct indeed : i should have mentionned that once loaded in memory, you can actually see the loaded dll (and functions?).

[erwan.l]

No, the more generic discussion is about developers (and particularly very good ones, like I consider both yourself and Olof ) should pass ANYTHING they produce through Okham's Razor, and if a simpler way exists, use it instead of any more complex one.

 

Wonko

 

...Or else pass it thru Wonko's review

 

As for developers, I feel flattered but I would not dare to compare my code to Olof's one.

I have been working a lot around Olof pieces of code (imdisk, devio, arsenal, ...) and this is excellent coding : well written, documented, reusable ...

 

Reading Olof's code is like looking at a beautiful woman : sit back, relax, and enjoy the view

[Wonko the Sane]

Hey, peeps, you forget how I am (besides grumpy) a hairy reasoner.
 
Forget all the theoretical stuff/fluff you seem to like discussing.
In theory there is a difference between static and dynamic loading and bla-bla-bla CFF and bla-bla-bla depends.exe and bla-bla-bla depends.exe profile the app (and what not, and the opposite of it)
 
BUT you can cry and stamp your feet as hard as you want, but if I open the libvmdk.dll  AND the zlib.dll shipped in erwan.l's package with CFF explorer, I can see FINE a dependency to msvcr120.dll in both, and by adding Olof's libvmdk.dll and zlib.dll (that show NOT such dependency) the proxy.dll works fine, so I seemingly just PROVED what I stated.
 
Thus it seems like BOTH the libvmdk.dll and zlib.dll shipped in erwan.l's package have a STATIC dependency to msvcr120.dll, libvmdk.dll has it TWICE, once directly and once through zlib.dll.
 
These dependencies are NOT NEEDED.
 
erwan.l shipped "botched" version of these two .dll's,a mistake can happen to everyone, no prob whatever , but my advice would be to replace them with the ones Olof provided that eliminate the need for msvcr120.dll.
 
 
 

...Or else pass it thru Wonko's review

Yep , you can trust me I won't let  get through unscathed things that shouldn't. 
 
 
 

As for developers, I feel flattered but I would not dare to compare my code to Olof's one.
I have been working a lot around Olof pieces of code (imdisk, devio, arsenal, ...) and this is excellent coding : well written, documented, reusable ...

Reading Olof's code is like looking at a beautiful woman : sit back, relax, and enjoy the view

I actually had the feeling that you had some problems ...

...with all due respect to Olof (and to his code) the alternative sounds better to me. 


Wonko

[erwan.l]

For the record, i actually found out that in VS2013 you can choose to build your project for XP

 

 

Or even better in our particular case, statically link your projejct (i.e no more dependency to msvcr120.dll).

 

/MT -> static

/MD -> dynaminc