Can't access hosts file or System32\drivers\etc on Vista x64

[chook]

I just ran into this issue myself using Windows 7 Professional 64 bit.

I can browse to C:\Windows\System32\drivers\ in XYplorer and see the following files & folders:
\en-US
\UMDF
winmount.sys
gmreadme.txt
gm.dls
and a .mrk file

Windows explorer shows the following in C:\Windows\System32\drivers\
\en-US
\etc
\UMDF
the file list above + over 300 .sys files

I saw your explanation on the redirect. Are there plans for a 64 bit version of XYplorer?

[admin]

I might add this to the FAQ on the homepage, but here it comes again:

It's caused WOW64 Redirection. And is what MS recommends to do:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.

Are there plans for a 64 bit version of XYplorer?

Sure, I'm just waiting for the technology to arrive (= the compiler).

[mwb1100]

Sure, I'm just waiting for the technology to arrive (= the compiler).

Is there something really going on here? Has someone decided to take on the task of creating a 64-bit 'classic' VB compiler (I'm pretty sure this is never coming from MS), or is XY's codebase moving to something other than VB6?

Or am I reading far too much into this?

[admin]

Sure, I'm just waiting for the technology to arrive (= the compiler).

Is there something really going on here? Has someone decided to take on the task of creating a 64-bit 'classic' VB compiler (I'm pretty sure this is never coming from MS), or is XY's codebase moving to something other than VB6?

Or am I reading far too much into this?

There is something going on. I just don't have any ETA yet.

[lukescammell]

Good to know, thanks Don

[admin]

Good to know, thanks Don

Yes, I'm now confident that 2011 will see XY64.

[lukescammell]

I'll hold you to that!

[bugger]

I realise the reason we don't have a 64bit version yet is that there isn't a 64bit capable VB compiler, but I do wonder what you plan on doing, Don, should there *never* be a 64bit VB compiler?

Write one myself. Of course, there's always the option to migrate to another language. Not nice, but many have gone this way since VB was abandoned by MS, so it's an option.

I don't follow, I don't use VB as much as I use .NET and C/C++, but I just built a project in Visual Studio 2010 using VB and compiled it to x64. I didn't see the option in the GUI strangely, but the /platform switch worked fine.

http://msdn.microsoft.com/en-us/library/8ck8e1y2.aspx

There are tons of benefits to going x64 over just shell extensions. One thing that annoys me on a daily basis is that I can't interact with Outlook - I can't drag attached files from email messages into XY. I have issues interacting with other x64 apps to including remote desktop and VMWare. The issues this thread mentions have annoyed me before.

I've reverted to running Explorer side by side with XY throughout the day over the last year, as a necessity. The world has moved to 64 bit but I'm kinda stuck in the middle!

[admin]

XY 64-bit is planned for 2011.

[Mesh]

I don't follow, I don't use VB as much as I use .NET and C/C++, but I just built a project in Visual Studio 2010 using VB and compiled it to x64. I didn't see the option in the GUI strangely, but the /platform switch worked fine.

The issue is that what you compiled is a .NET application - meaning that it's managed and requires the .NET Framework. VB6, which is what XY is coded in, is unmanaged (which is, in my mind, superior). Microsoft stopped supporting an unmanaged version of Visual Basic after VB6. That's the problem.

[bugger]

The issue is that what you compiled is a .NET application - meaning that it's managed and requires the .NET Framework. VB6, which is what XY is coded in, is unmanaged (which is, in my mind, superior). Microsoft stopped supporting an unmanaged version of Visual Basic after VB6. That's the problem.

I would have agreed in the past and in some cases I still would, though it's been proven that .NET compiles to a very well optimized executable, making tough competition for even unmanaged code. Of course it depends who you are and what you like, but the new .NET 4.0 WPF libraries are letting us create some beautiful new user interfaces in small amounts of code that you just can't touch otherwise without shit-tons of work.

[Mesh]

I would have agreed in the past and in some cases I still would, though it's been proven that .NET compiles to a very well optimized executable, making tough competition for even unmanaged code. Of course it depends who you are and what you like, but the new .NET 4.0 WPF libraries are letting us create some beautiful new user interfaces in small amounts of code that you just can't touch otherwise without shit-tons of work.

I can't speak for others, but for me personally, I don't like unnecessary dependencies. If I code an app, I want it to be able to run wherever it's executed and not be dependant on whether or not a framework is installed, whether it's working correctly, whether the framework developer has decided to give up on it, etc...

Companies keep pushing dependency based "solutions" on people (web apps being a great example), and make it sound like the best thing since sliced bread - until something goes wrong. Then everybody who depended on it is up the creek without a paddle, while the "old school" folks are able to keep working.


I'll stick with unmanaged apps, myself.


As for the difference in time, it reminds me of the arguments you see often about low level languages like C++ versus higher level languages like Python: that it will take six months longer to code an app in C++ because of all the extra micromanaging code, instead of the higher level language having built in functions for higher level actions.

All that means is that you code your function library first, and afterwards you can code apps just as quickly with just as few lines as you would any other language.

[bugger]

Companies keep pushing dependency based "solutions" on people (web apps being a great example), and make it sound like the best thing since sliced bread - until something goes wrong. Then everybody who depended on it is up the creek without a paddle, while the "old school" folks are able to keep working.

I'll stick with unmanaged apps, myself.

Hehe, I hear ya Mesh and in some circumstances I agree. We built a product that had to be cross-platform and ultra fast. Instead of going with Java we went with pure C, and built our own libraries. Down the road it proved to be a bit of an issue regarding how the vector code was working but we dealt with it, and damn-sure it's fast as hell.

It's hard to deny the power of .NET, especially with something like what Don's doing - a file system interface for Windows systems. I can't speak to his requirements of course, but it's pretty painless to require a .NET version and you know that one of Microsoft's primary goals are maintaining backwards-compatibility in future versions.

A friend of mine owns a company building high-def underwater Sonar devices. They built all their graphics libraries in C/C++. He's an old school engineer and he asked me the other week about WPF. Now he's totally loving what it can do for his clients and he's building his next release using WPF.

I look forward to hearing what Don chooses for the 2011 XY, which language and compiler he decides on. Whether it's C/C++ or .NET might make a difference to me. I'm kinda sick of looking at Windows Forms apps after seeing what WPF can do. I know, shoot me for harping on WPF so much I sound like a fanboy.