Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add amd64 adm stub for call_method, fix MSVC/amd64 buil...

[Jérôme Gardou]

Le 23/08/2011 10:58, tkreuzer(a)svn.reactos.org a écrit :
>   Author: tkreuzer
>  Date: Tue Aug 23 08:58:15 2011
>  New Revision: 53399
>
>  URL: http://svn.reactos.org/svn/reactos?rev=53399&view=rev
>  Log:
>  [VMWINST] Fix amd64 build
>  
What about :
[VMWINST] Get rid of this useless relic.
I mean it's something we have to maintain, it was written for 
antediluvian vmware versions, and I see no reason to have such a thing. 
I may as well write an application to install specific ATI card drivers, 
or intel chipset drivers...

[Aleksey Bragin]

What about :
[VMWINST] Get rid of this useless relic.
I mean it's something we have to maintain, it was written for
antediluvian vmware versions, and I see no reason to have such a thing.
I may as well write an application to install specific ATI card drivers,
or intel chipset drivers...


It's written for the most common testing platform of ReactOS, the 
maintaining effort spent over years was minimal, and it just does its job 
very quickly, even with VMWare 7 (provided you copy necessary video driver 
files from its CD to modules\optional when building your bootcd).

WBR,
Aleksey.

[Bernd Blaauw]

Op 4-9-2011 17:24, Aleksey Bragin schreef:
>   It's written for the most common testing platform
> of ReactOS, the
>  maintaining effort spent over years was minimal, and it just does its
>  job very quickly, even with VMWare 7 (provided you copy necessary video
>  driver files from its CD to modules\optional when building your bootcd). 
Is this documented somewhere including a howto, for 'most common testing 
platform'?
I was under the impression VMWINST was only able to handle old ISO 
structure of Vmware tools, not new tools ISO (despite me having 
explained structure before, and 7zip doing the job), nor your above 
listed method. If it actually works, good news (for vmwinst.exe in phase 
3). Having to rebuild CD instead of pointing to files on a CD or 
directory, is an annoying requirement however.

>   WBR,
>  Aleksey. 
thanks for above info. Gives some hope after having messed around with 
FreeLDR all day in vain.

[Javier Agustìn Fernàndez Arroyo]

well i think nowadays 'most common testing platform' is VirtualBox, not sure
about VMWare.....

On Sun, Sep 4, 2011 at 5:34 PM, Bernd Blaauw <bblaauw(a)home.nl> wrote:

>   Op 4-9-2011 17:24, Aleksey Bragin schreef:
>
>   It's written for the most common testing platform of ReactOS, the
> >   maintaining effort spent over years was minimal,
> > and it just does its
> >  job very quickly, even with VMWare 7 (provided you copy necessary video
> >  driver files from its CD to modules\optional when building your bootcd).
> >  
>  Is this documented somewhere including a howto, for 'most common testing
>  platform'?
>  I was under the impression VMWINST was only able to handle old ISO
>  structure of Vmware tools, not new tools ISO (despite me having explained
>  structure before, and 7zip doing the job), nor your above listed method. If
>  it actually works, good news (for vmwinst.exe in phase 3). Having to rebuild
>  CD instead of pointing to files on a CD or directory, is an annoying
>  requirement however.
>
>   WBR,
> >   Aleksey.
> >  
>  thanks for above info. Gives some hope after having messed around with
>  FreeLDR all day in vain.
>
>
>  ______________________________**_________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>
> http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
>

[Sylvain Petreolle]

Vmwinst was meant to work with old vmware layout, and it grabbed the files automatically.
Now you have to extract the files from the MSI package in order to have it working,
which is far from a convenient way.

I don't know what is the benefit to use vmware's video driver either, as we can
now switch video resolution on the fly.


Kind regards,
Sylvain Petreolle


>  ________________________________
> De : Aleksey Bragin <aleksey(a)reactos.org>
> À : ReactOS Development List <ros-dev(a)reactos.org>
> Envoyé le : Dimanche 4 Septembre 2011 17h24
> Objet : Re: [ros-dev] [ros-diffs] [tkreuzer] 53399: [VMWINST] Fix amd64 build [NTDLL] add
> missing amd64 specific exports [MSVCRT*] Fix mangled c++ exports for amd64 [OLEAUT32] Add
> amd64 adm stub for call_method, fix MSVC/amd64 buil...
>
> What about :
> [VMWINST] Get rid of this useless relic.
> I mean it's something we have to maintain, it was written for
> antediluvian vmware versions, and I see no reason to have such a thing.
> I may as well write an application to install specific ATI card drivers,
> or intel chipset drivers...
>
>
> It's written for the most common testing platform of ReactOS, the maintaining effort
> spent over years was minimal, and it just does its job very quickly, even with VMWare 7
> (provided you copy necessary video driver files from its CD to modules\optional when
> building your bootcd).
>
> WBR,
> Aleksey. 
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>

[Bernd Blaauw]

Op 4-9-2011 19:21, Sylvain Petreolle schreef:
>   Vmwinst was meant to work with old vmware layout, and
> it grabbed the files automatically.
>  Now you have to extract the files from the MSI package in order to have it working,
>  which is far from a convenient way. 
If "vmwinst.exe" or the "new hardware wizard" would accept a directory

with the VMware drivers, great. Setup phase 2 VMWINST definately doesn't 
work (for later ISO, as you mention above), so you're right it's 
pointless there. Being able to supply a USB flash disk, floppy, 
harddrive directory or some custom directory with the proper drivers, 
would be nice.

Or alternatively, 'just' have the MSI file work properly (which is 
horribly difficult or this situation wouldn't exist in the first place)

>   I don't know what is the benefit to use
> vmware's video driver either, as we can now switch video resolution on the fly.
Hardware Acceleration ? 3D Hardware OpenGL? Proper resolutions (for 
widescreens) ? A generic/universal/simple VESA driver has its limitations.

Since when vmware is the most common testing platform?:> I also agree, tha Vbox has
taken up the first place... This module is not working properly, due to changes in Vmware
7 (and perhaps even earlier). Sure, you can hack around it, by providing the driver
manually... but its not what this module was supposed to do in the first place?

What's worse, it is using some ugly methode of detecting Vmware host, by probing one
specific pipe. On other hosts, this attempt throws an exception. If we plan to run ROS
tests with /FIRSTCHANCE this module needs to disappear.

In my opinion, VMWINST should either be fixed to deal with new Vmware, or be sent to its
hard-earned retirement.

On Sun, 04 Sep 2011 19:41 +0200, "Bernd Blaauw" <bblaauw(a)home.nl> wrote:
>   Op 4-9-2011 19:21, Sylvain Petreolle schreef:
>  > Vmwinst was meant to work with old vmware layout, and it grabbed the files
> automatically.
>  > Now you have to extract the files from the MSI package in order to have it working,
>  > which is far from a convenient way. 
-- 
With best regards
Caemyr

[Bernd Blaauw]

Op 4-9-2011 20:50, caemyr(a)myopera.com schreef:
>   What's worse, it is using some ugly methode of
> detecting Vmware host, by probing one specific pipe. On other hosts, this attempt throws
> an exception. If we plan to run ROS tests with /FIRSTCHANCE this module needs to
> disappear.
>
>  In my opinion, VMWINST should either be fixed to deal with new Vmware, or be sent to its
> hard-earned retirement. 
The sooner it's redundant/obsolete, the better indeed. Unfortunately not 
the case yet. Scanning for PCI device "15ad:0405" might do the trick as 
well, instead of relying on magic from
http://sites.google.com/site/chitchatvmback/backdoor

Anyway, goodluck dealing with this in a sane way :)

[Aleksey Bragin]

-----Original Message----- 
From: caemyr(a)myopera.com
Sent: Sunday, September 04, 2011 10:50 PM
To: ReactOS Development List
Subject: Re: [ros-dev] [VMWINST]

>  Since when vmware is the most common testing
> platform?:> I also agree, tha 
> Vbox has taken up the first place... 
I forgot to put on the ironic tag :) But
seriously, it's one of the most 
popular platforms. Vbox has really taken up the first place, I suppose.

>  This module is not working properly, due to changes in
> Vmware 7 (and 
> perhaps even earlier). Sure, you can hack around it, by providing the 
> driver manually... but its not what this module was supposed to do in the 
> first place? 
The thing is, yes there is aproblem with autograbbing the modules, but if 
you put them in proper place by yourself, it works flawlessly, and automates 
their installation to the point when I just can choose the necessary 
resolution and color depth at install time and everything else is done 
within 5 seconds.

>   What's worse, it is using some ugly methode of
> detecting Vmware host, by 
>  probing one specific pipe. On other hosts, this attempt throws an 
>  exception. If we plan to run ROS tests with /FIRSTCHANCE this module needs 
>  to disappear. 
This is not an ugly or a beautiful method, it is a method to detect
presence 
of a VMWare virtual machine described here:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cm…
It's also smartly wrapped into a VEH which would catch the exception on 
other hardware (that's normal, nothing extraordinary).

Rather, it's possible to hack away all possible first chance exceptions to 
be able to run with /FIRSTCHANCE, but I doubt it's the right way. Are there 
any other cases except vmwinst when an exception happens by design?

>   In my opinion, VMWINST should either be fixed to deal
> with new Vmware, or 
>  be sent to its hard-earned retirement. 
For me that would mean a substantial
increase in a usual testing cycle 
duration, because I would need to install VMWare Tools (do they even work?) 
or cope with default ReactOS VESA driver (which sucks performance-wise 
compared to fast VMWare's one).

WBR,
Aleksey.

[Alex Ionescu]

Aleksey,

Didn't you promise me 1.5 years ago that you'd make running VMWare Tools
your #1 priority "as soon as the heap stuff is done"...?

Best regards,
Alex Ionescu


On Sun, Sep 4, 2011 at 10:01 PM, Aleksey Bragin <aleksey(a)reactos.org> wrote:

>  
>
>  -----Original Message----- From: caemyr(a)myopera.com
>  Sent: Sunday, September 04, 2011 10:50 PM
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] [VMWINST]
>
>
>   Since when vmware is the most common testing platform?:> I also agree, tha
> >   Vbox has taken up the first place...
> >  
>  I forgot to put on the ironic tag :) But seriously, it's one of the most
>  popular platforms. Vbox has really taken up the first place, I suppose.
>
>
>   This module is not working properly, due to changes in Vmware 7 (and
> >   perhaps even earlier). Sure, you can hack around
> > it, by providing the driver
> >  manually... but its not what this module was supposed to do in the first
> >  place?
> >  
>  The thing is, yes there is aproblem with autograbbing the modules, but if
>  you put them in proper place by yourself, it works flawlessly, and automates
>  their installation to the point when I just can choose the necessary
>  resolution and color depth at install time and everything else is done
>  within 5 seconds.
>
>
>   What's worse, it is using some ugly methode of detecting Vmware host, by
> >   probing one specific pipe. On other hosts, this
> > attempt throws an exception.
> >  If we plan to run ROS tests with /FIRSTCHANCE this module needs to
> >  disappear.
> >  
>  This is not an ugly or a beautiful method, it is a method to detect
>  presence of a VMWare virtual machine described here:
>  http://kb.vmware.com/**selfservice/microsites/search.**
>
> do?language=en_US&cmd=**displayKC&externalId=1009458<http://kb.v…
>  It's also smartly wrapped into a VEH which would catch the exception on
>  other hardware (that's normal, nothing extraordinary).
>
>  Rather, it's possible to hack away all possible first chance exceptions to
>  be able to run with /FIRSTCHANCE, but I doubt it's the right way. Are there
>  any other cases except vmwinst when an exception happens by design?
>
>
>   In my opinion, VMWINST should either be fixed to deal with new Vmware, or
> >   be sent to its hard-earned retirement.
> >  
>  For me that would mean a substantial increase in a usual testing cycle
>  duration, because I would need to install VMWare Tools (do they even work?)
>  or cope with default ReactOS VESA driver (which sucks performance-wise
>  compared to fast VMWare's one).
>
>  WBR,
>  Aleksey.
>
>  ______________________________**_________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>
> http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
>

@Alex

http://www.reactos.org/bugzilla/show_bug.cgi?id=5652

First thing that needs to be fixed for Tools.

On Sun, 04 Sep 2011 23:38 +0100, "Alex Ionescu" <ionucu(a)videotron.ca>
wrote:
>   Aleksey,
>  
>  Didn't you promise me 1.5 years ago that you'd make running VMWare Tools
>  your #1 priority "as soon as the heap stuff is done"...?
>  
>  Best regards,
>  Alex Ionescu
>  
>  
>  On Sun, Sep 4, 2011 at 10:01 PM, Aleksey Bragin <aleksey(a)reactos.org>
>  wrote:
>  
> >  
> >
> >  -----Original Message----- From: caemyr(a)myopera.com
> >  Sent: Sunday, September 04, 2011 10:50 PM
> >  To: ReactOS Development List
> >  Subject: Re: [ros-dev] [VMWINST]
> >
> >
> >   Since when vmware is the most common testing platform?:> I also agree, tha
> > >   Vbox has taken up the first place...
> > >  
> >  I forgot to put on the ironic tag :) But seriously, it's one of the most
> >  popular platforms. Vbox has really taken up the first place, I suppose.
> >
> >
> >   This module is not working properly, due to changes in Vmware 7 (and
> > >   perhaps even earlier). Sure, you can hack around
> > > it, by providing the driver
> > >  manually... but its not what this module was supposed to do in the first
> > >  place?
> > >  
> >  The thing is, yes there is aproblem with autograbbing the modules, but if
> >  you put them in proper place by yourself, it works flawlessly, and automates
> >  their installation to the point when I just can choose the necessary
> >  resolution and color depth at install time and everything else is done
> >  within 5 seconds.
> >
> >
> >   What's worse, it is using some ugly methode of detecting Vmware host, by
> > >   probing one specific pipe. On other hosts, this
> > > attempt throws an exception.
> > >  If we plan to run ROS tests with /FIRSTCHANCE this module needs to
> > >  disappear.
> > >  
> >  This is not an ugly or a beautiful method, it is a method to detect
> >  presence of a VMWare virtual machine described here:
> >  http://kb.vmware.com/**selfservice/microsites/search.**
> >
> > do?language=en_US&cmd=**displayKC&externalId=1009458<http://kb.v…
> >  It's also smartly wrapped into a VEH which would catch the exception on
> >  other hardware (that's normal, nothing extraordinary).
> >
> >  Rather, it's possible to hack away all possible first chance exceptions to
> >  be able to run with /FIRSTCHANCE, but I doubt it's the right way. Are there
> >  any other cases except vmwinst when an exception happens by design?
> >
> >
> >   In my opinion, VMWINST should either be fixed to deal with new Vmware, or
> > >   be sent to its hard-earned retirement.
> > >  
> >  For me that would mean a substantial increase in a usual testing cycle
> >  duration, because I would need to install VMWare Tools (do they even work?)
> >  or cope with default ReactOS VESA driver (which sucks performance-wise
> >  compared to fast VMWare's one).
> >
> >  WBR,
> >  Aleksey.
> >
> >  ______________________________**_________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >
> > http://www.reactos.org/**mailman/listinfo/ros-dev<http://www.reactos.org…
> >  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 

-- 
With best regards
Caemyr

[Bernd Blaauw]

Op 4-9-2011 17:10, Jérôme Gardou schreef:
>   Le 23/08/2011 10:58, tkreuzer(a)svn.reactos.org a écrit
> :
>  What about :
>  [VMWINST] Get rid of this useless relic.
>  I mean it's something we have to maintain, it was written for
>  antediluvian vmware versions, and I see no reason to have such a thing.
>  I may as well write an application to install specific ATI card drivers,
>  or intel chipset drivers... 
Well you got multiple options:
* ensure the VMware installer (MSI) can run properly so people can 
install their drivers. Makes VMWINST obsolete.
* ensure ReactOS can deal with a directory containing the bare VMware 
drivers (requiring 7zip to extract them from VMware 7 ISO).
* convert the Linux opensource VMware drivers into NT ones
* update this relic tool to finally (also) work with modern VMware ISO 
contents structure.

Nice and all that people can show off Quake2, Furmark etc in 
VirtualBox..now prove the same for other virtualisation products and 
real hardware graphics cards (Nvidia and AMD/ATI for starters, Intel 
graphics if you aim at business desktops).

Demonstrate equal progress in all used/supported platforms. Show VMWINST 
is an obsolete relic by proving VMware drivers can install on trunk 
ReactOS, including the added 3D support (OpenGL only I guess, but good 
enough for now).

[Jérôme Gardou]

Le 04/09/2011 17:29, Bernd Blaauw a écrit :
>   Op 4-9-2011 17:10, Jérôme Gardou schreef:
> >   Le 23/08/2011 10:58, tkreuzer(a)svn.reactos.org a
> > écrit :
> >  What about :
> >  [VMWINST] Get rid of this useless relic.
> >  I mean it's something we have to maintain, it was written for
> >  antediluvian vmware versions, and I see no reason to have such a thing.
> >  I may as well write an application to install specific ATI card drivers,
> >  or intel chipset drivers... 
>  Well you got multiple options:
>  * ensure the VMware installer (MSI) can run properly so people can 
>  install their drivers. Makes VMWINST obsolete.
>  * ensure ReactOS can deal with a directory containing the bare VMware 
>  drivers (requiring 7zip to extract them from VMware 7 ISO).
>  * convert the Linux opensource VMware drivers into NT ones
>  * update this relic tool to finally (also) work with modern VMware ISO 
>  contents structure.
>
>  Nice and all that people can show off Quake2, Furmark etc in 
>  VirtualBox..now prove the same for other virtualisation products and 
>  real hardware graphics cards (Nvidia and AMD/ATI for starters, Intel 
>  graphics if you aim at business desktops).
>
>  Demonstrate equal progress in all used/supported platforms. Show 
>  VMWINST is an obsolete relic by proving VMware drivers can install on 
>  trunk ReactOS, including the added 3D support (OpenGL only I guess, 
>  but good enough for now).
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Please, stop asking us to
"port opensource linux drivers into NT ones". 
And also don't answer to this sentence and try to explain us why it 
would be so good for this project.
There's no offence meant, it's just that we don't have interest into it, 
and we lack manpower anyway.

Also, Aleksey noted that he still had use of this, I won't touch it.