Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1080 > unrolled thread

VB.net (2010) Beginner Question: Directory Lists

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-19 22:10 -0700
    Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-20 10:24 +0100
    Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-20 09:41 -0400
    Re: VB.net (2010) Beginner Question: Directory Lists "Auric__" <not.my.real@email.address> - 2012-05-20 19:27 +0000
      Re: VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-20 19:06 -0700
        Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-20 23:32 -0400
          Re: VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-20 22:05 -0700
        Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-23 01:37 +1000
          Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 13:24 -0400
            Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 11:30 -0600
              Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 14:03 -0400
                Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 12:15 -0600
                  Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 15:05 -0400
                    Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 14:01 -0600
                      Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 17:29 -0400
                        Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 17:13 -0600
                          Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-23 09:10 -0400
                            Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-23 10:24 -0600
                    Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 14:37 -0600
                      Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 10:55 -0400
              Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 14:38 -0400
                Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 12:47 -0600
            Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-24 23:44 +1000
              Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-24 10:07 -0400
              Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-24 16:07 +0100
                Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-24 09:57 -0600
                Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-25 18:39 +1000
                  Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-25 11:23 +0100
                    Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-27 23:07 +1000
                      Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-27 16:44 +0100
                      Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-27 17:12 -0500
                        Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-30 07:04 +0100
                          Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-30 02:36 -0500
                            Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-31 08:54 +0100
                              Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-31 10:33 -0500
                        Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-30 23:19 +1000
                          Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-30 14:09 -0500
          Re: VB.net (2010) Beginner Question: Directory Lists GS <gs@somewhere.net> - 2012-05-25 13:44 -0400
            Re: VB.net (2010) Beginner Question: Directory Lists -mhd <not_real@invalid.com> - 2012-05-25 17:47 -0400
              Re: VB.net (2010) Beginner Question: Directory Lists GS <gs@somewhere.net> - 2012-05-25 19:51 -0400
        Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 11:09 -0600
          Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-23 13:07 +0100
            Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-23 10:14 -0600
              Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-24 20:38 +0200
                Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-24 15:46 -0600
                  Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-25 06:52 +0100
                  Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-25 11:14 +0200
                    Re: VB.net (2010) Beginner Question: Directory Lists "DaveO" <djo@dial.pipex.com> - 2012-05-25 10:57 +0100
                      Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-25 13:36 +0200
                    Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 09:25 -0400
                    Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-25 10:12 -0600
                      Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 12:27 -0400
                        Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-25 14:22 -0600
                      Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-26 18:38 +0200
                        Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 14:12 -0600
                          Re: VB.net (2010) Beginner Question: Directory Lists "Henning" <computer_hero@coldmail.com> - 2012-05-26 23:31 +0200
                            Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-26 18:07 -0400
                              Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 16:50 -0600
                                Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-26 20:53 -0400
                                  Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 20:31 -0600
                                    Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-27 09:49 -0400
                                Re: VB.net (2010) Beginner Question: Directory Lists Karl E. Peterson <karl@exmvps.org> - 2012-05-29 12:50 -0700
                                  Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-29 19:14 -0400
                                    Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-29 18:25 -0500
                                    Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-30 06:51 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#1080 — VB.net (2010) Beginner Question: Directory Lists

Hi All,

This is an extreme beginner question so if these type of questions
annoy you then probably best not read this one.

For those of you willing to help this will be a great learning xp for
me.


B'Ground: I am created an app that will catelogue short videos of the
signs (sign language) of a woman who has a disability.

As I am an extreme novice I am having trouble adding flexibility to
the list of video files that the program displays

Ultimately I want the app to:
1. Get the addresses of contents of a specified directory with the
*.wmv extension and place these addresses in an array (arrFileAddress)
2. Get the name of each file within this array WITHOUT the address (c:
\whatever...) and without the extention (.wmv) so that "C:\Whatever
\Barbeque.wmv" = "Barbeque",  and place these into a listbox so that
when the user clicks on a Word (ie. "Barbeque") I can pass the address
to the WindowsMediaPlayer Object as an input to play the file

So...

I have been able to find the followingwith endless searching

[code]
' make a reference to a directory
    Dim di As New IO.DirectoryInfo("c:\")
    Dim diar1 As IO.FileInfo() = di.GetFiles()
    Dim dra As IO.FileInfo

   'list the names of all files in the specified directory
    For Each dra In diar1
        ListBox1.Items.Add(dra)
    Next
[/code]

Thsi obviously gives me a string array of the file addresses and
names;

how can I now filter out the address and extension text and just
display the word?


Thanks so much for any help you can offer.

[toc] | [next] | [standalone]

#1081

"Sandwich" <liam.whan@gmail.com> wrote in message 
news:ecf4ddec-cccd-4eaa-a24b-7a0e22213b9f@ns1g2000pbc.googlegroups.com...

> This is an extreme beginner question so if these type
> of questions annoy you then probably best not read
> this one.

Beginners' questions don't annoy me at all, but it might be best if you were 
to begin in the right place. This group is for the real Visual Basic 
(Classic VB6 and earlier) whereas you are using the dotnet imposter which is 
a completely different thing and which, despite its deliberately misleading 
marketing name, is not Visual Basic at all. Try posting your question to a 
dotnet group or to one of Micro$oft's new fangled and heavily policed dotnet 
forums.

Mike

[toc] | [prev] | [next] | [standalone]

#1082

The newsgroup Mike is referring to is here:

microsoft.public.dotnet.languages.vb

  But it may not be very busy. Microsoft officially
ended support for their own newgroups, so MVPs don't
get any points for answering newsgroup questions.
As a result, most MVPs immediately switched to the
webpage forums and the newsgroups have become
relatively quiet.

  There's a webpage forum for VB.Net here:

http://social.msdn.microsoft.com/Forums/en/vbgeneral/threads

  The forums get more traffic but they're moderated,
awkward to use, and require that you "join the club"
as a member before you can post. They also have a
general marketing slant. Microsoft is specifically avoiding
any sort of forum where programmers can discuss freely.
Their web forums -- both in content and in categories
available -- are designed to market Microsoft products.

  There may be good reason that you're using .Net. You
didn't explain that. But personally, if I were doing something
like what you plan I think I'd do it with an HTA using VBScript.
What you want to achieve is very basic. It can probably be
done quickly and easily with script. With VB.Net 2010, anyone
who wants to run your software will need something like 1/2
GB of .Net Framework files, for what can be done in a few
KB with script. .Net Framework 4 (2010 version) is not
pre-installed on any Windows version. In other words, you're
planning to use an 18-wheeler to ship a letter-size package.

 .Net was never really designed for Windows software. It is a
Java clone, designed for writing server-side applets and "web
services":

http://www.microsoft.com/en-us/news/press/2000/jul00/pdcdeliverspr.aspx

  Microsoft are trying to push 3rd-party developers, other
than approved partners, out of the Windows platform. So
they pretended that .Net was good for writing Windows
software. ...Ever wonder why .Net is supposedly well-suited
for Windows software despite the fact that Java has been
around much longer and is rarely used for Windows software?

  Now .Net is being retooled so that people can write Metro
trinkets with it. For Metro you'll need the same 1/2 GB of support
files to write a program using the WinRT API. So .Net will load
to call WinRT, which will load to call the Win32 API with restricted
access, all to produce something surprisingly similar to an HTA!
Your letter-size package will now be shipping via ocean liner. :)

| how can I now filter out the address and extension text and just
| display the word?

  That's a good example of something that script is well-suited
for. With the FileSystemObject in VBScript, it's easy to get a
list of files in a folder, and there's even a specific method for
getting a file name from a path:  GetBaseName
  With script in an HTA it's easy to add those names to a SELECT
element, which is essentially a listbox.

----------------------------------------

--
"Sandwich" <liam.whan@gmail.com> wrote in message 
news:ecf4ddec-cccd-4eaa-a24b-7a0e22213b9f@ns1g2000pbc.googlegroups.com...
| Hi All,
|
| This is an extreme beginner question so if these type of questions
| annoy you then probably best not read this one.
|
| For those of you willing to help this will be a great learning xp for
| me.
|
|
| B'Ground: I am created an app that will catelogue short videos of the
| signs (sign language) of a woman who has a disability.
|
| As I am an extreme novice I am having trouble adding flexibility to
| the list of video files that the program displays
|
| Ultimately I want the app to:
| 1. Get the addresses of contents of a specified directory with the
| *.wmv extension and place these addresses in an array (arrFileAddress)
| 2. Get the name of each file within this array WITHOUT the address (c:
| \whatever...) and without the extention (.wmv) so that "C:\Whatever
| \Barbeque.wmv" = "Barbeque",  and place these into a listbox so that
| when the user clicks on a Word (ie. "Barbeque") I can pass the address
| to the WindowsMediaPlayer Object as an input to play the file
|
| So...
|
| I have been able to find the followingwith endless searching
|
| [code]
| ' make a reference to a directory
|    Dim di As New IO.DirectoryInfo("c:\")
|    Dim diar1 As IO.FileInfo() = di.GetFiles()
|    Dim dra As IO.FileInfo
|
|   'list the names of all files in the specified directory
|    For Each dra In diar1
|        ListBox1.Items.Add(dra)
|    Next
| [/code]
|
| Thsi obviously gives me a string array of the file addresses and
| names;
|
| how can I now filter out the address and extension text and just
| display the word?
|
|
| Thanks so much for any help you can offer. 

[toc] | [prev] | [next] | [standalone]

#1083

Sandwich wrote:

[snip]
> I have been able to find the followingwith endless searching
>
> [code]
> ' make a reference to a directory
>     Dim di As New IO.DirectoryInfo("c:\")
>     Dim diar1 As IO.FileInfo() = di.GetFiles()
>     Dim dra As IO.FileInfo
>
>    'list the names of all files in the specified directory
>     For Each dra In diar1
>         ListBox1.Items.Add(dra)
>     Next
> [/code]
>
> Thsi obviously gives me a string array of the file addresses and
> names;
>
> how can I now filter out the address and extension text and just
> display the word?

On the one hand, your problem is trivially easy, and there are several ways 
to go about doing what you need. Any place you need just the filename of 
"dra", I think I would use something like this:
  dra.Name.Substring(0, dra.Name.IndexOf("."))

So, if you wanted to load your listbox with the filenames, you could do 
this:
  ListBox1.Items.Add(dra.Name.Substring(0, dra.Name.IndexOf(".")))


On the other hand, I agree with Mike and Mayayana: this is not a .Net 
group. I *especially* agree with Mayayana about the unnecessary bloat and 
BS that .Net requires. Instead of scripting, which he discusses a bit, I 
just switched to a different language entirely, FreeBASIC:
  http://www.freebasic.net/
Based on, and almost 100% compatible with, QuickBASIC (MS's old DOS 
compiler), with the added advantage of being completely free.

Alternately, there are many, many other BASICs that work with Windows and 
are much less bloated than VB.Net. I suggest PowerBASIC, REAL Studio, or 
Liberty Basic.
- PowerBASIC is my overall favorite BASIC (but I don't use it much because 
I program for Linux, which PB doesn't support -- and windows are a bit more 
difficult):
  http://www.powerbasic.com/
- REAL Studio is somewhat VB-like and has probably the best support for 
windows (forms) outside of Microsoft's products:
  http://www.realsoftware.com/
- Liberty Basic is *very* easy to learn, but compiles to bytecode rather 
than machine code (not really a problem, but something to be aware of):
  http://www.libertybasic.com/

-- 
I want to be cremated, and I want my ashes blown in Uri Geller's eyes.
 -- James Randi (skeptic)

[toc] | [prev] | [next] | [standalone]

#1084

On May 21, 5:27 am, "Auric__" <not.my.r...@email.address> wrote:
> Sandwich wrote:
>
> [snip]
>
>
>
>
>
>
>
>
>
> > I have been able to find the followingwith endless searching
>
> > [code]
> > ' make a reference to a directory
> >     Dim di As New IO.DirectoryInfo("c:\")
> >     Dim diar1 As IO.FileInfo() = di.GetFiles()
> >     Dim dra As IO.FileInfo
>
> >    'list the names of all files in the specified directory
> >     For Each dra In diar1
> >         ListBox1.Items.Add(dra)
> >     Next
> > [/code]
>
> > Thsi obviously gives me a string array of the file addresses and
> > names;
>
> > how can I now filter out the address and extension text and just
> > display the word?
>
> On the one hand, your problem is trivially easy, and there are several ways
> to go about doing what you need. Any place you need just the filename of
> "dra", I think I would use something like this:
>   dra.Name.Substring(0, dra.Name.IndexOf("."))
>
> So, if you wanted to load your listbox with the filenames, you could do
> this:
>   ListBox1.Items.Add(dra.Name.Substring(0, dra.Name.IndexOf(".")))
>
> On the other hand, I agree with Mike and Mayayana: this is not a .Net
> group. I *especially* agree with Mayayana about the unnecessary bloat and
> BS that .Net requires. Instead of scripting, which he discusses a bit, I
> just switched to a different language entirely, FreeBASIC:
>  http://www.freebasic.net/
> Based on, and almost 100% compatible with, QuickBASIC (MS's old DOS
> compiler), with the added advantage of being completely free.
>
> Alternately, there are many, many other BASICs that work with Windows and
> are much less bloated than VB.Net. I suggest PowerBASIC, REAL Studio, or
> Liberty Basic.
> - PowerBASIC is my overall favorite BASIC (but I don't use it much because
> I program for Linux, which PB doesn't support -- and windows are a bit more
> difficult):
>  http://www.powerbasic.com/
> - REAL Studio is somewhat VB-like and has probably the best support for
> windows (forms) outside of Microsoft's products:
>  http://www.realsoftware.com/
> - Liberty Basic is *very* easy to learn, but compiles to bytecode rather
> than machine code (not really a problem, but something to be aware of):
>  http://www.libertybasic.com/
>
> --
> I want to be cremated, and I want my ashes blown in Uri Geller's eyes.
>  -- James Randi (skeptic)

Wow,

thankyou all for taking the time to respond so quickly and completely,
and apologies for posting a heretic .NET question in here, as a new
hobbyist programmer it was ignorance rather than malice!

BTW you've convinced me to switch. I chose VB.net as I'm a new
programmer and the temptation is to think that you might as well learn
the most current imprint of the language.

I'm writing this software for deloyment on workstations that are
connected to a pretty tightly controlled Gov network, and when I tried
to run a debug build .exe of my app on my workstation at work I got a
dailog saying "you need to install .net redistributable packge
4.xxxx", which worried me as I want this to useable on in as many
environments as possible so it can be of assistance to staff who work
with this lady in a variety of places (day programs, etc)

So in short; I'm going to take your advice and switch languages! So
can I confirm that VB6 would also be an appropriate choice? Its just
that there is a LOT of forum support etc for VB6 and that it very
tempting.

I'll head off and try freebasic (I programmed a little when I was 8 in
QBasic so I'm looking foward to seeing this!)  and the trial of REAL
studio; I guess what I REALLY need is something that has a LOT of
developer support on the web so I can find help easily and not have to
bother you good folk!

Thanks again!

Liam.

P.s. *tips hat to JAmes Randi quote* "a genius of our times." Ricky
Gervais

[toc] | [prev] | [next] | [standalone]

#1085

>
So in short; I'm going to take your advice and switch languages! So
can I confirm that VB6 would also be an appropriate choice? Its just
that there is a LOT of forum support etc for VB6 and that it very
tempting.
>

  VB6 would be fine, and you won't need to install any support
files. You can also get help here and there's lots of free code
around. But be aware that VB6 is no longer officially supported.
Microsoft is not yet trying to kill it. VB6 software runs on Win8
with no extra files needed. It pretty much runs on any Windows
computer now in use. In fact, VB6 is arguably the most widely
supported tool for Windows programming. (C++ is widely supported,
by VC++ has a different runtime for each version, so the later
the version you use the more target machines need runtimes
installed.)

   But VB6 won't be usable for Metro phone/
tablet apps, and while it can run on Win64, it can't run as
64-bit. That means, for instance, that if you write an IE browser
extension, Explorer Bar, etc., those can only be used in the 32
bit version of IE and Explorer respectively. Over time those
limitations may become notable. For the forseeable future,
however, they're not relevant unless you want to target Metro. 

[toc] | [prev] | [next] | [standalone]

#1086

On May 21, 1:32 pm, "Mayayana" <mayay...@invalid.nospam> wrote:
> So in short; I'm going to take your advice and switch languages! So
> can I confirm that VB6 would also be an appropriate choice? Its just
> that there is a LOT of forum support etc for VB6 and that it very
> tempting.
>
>
>
>   VB6 would be fine, and you won't need to install any support
> files. You can also get help here and there's lots of free code
> around. But be aware that VB6 is no longer officially supported.
> Microsoft is not yet trying to kill it. VB6 software runs on Win8
> with no extra files needed. It pretty much runs on any Windows
> computer now in use. In fact, VB6 is arguably the most widely
> supported tool for Windows programming. (C++ is widely supported,
> by VC++ has a different runtime for each version, so the later
> the version you use the more target machines need runtimes
> installed.)
>
>    But VB6 won't be usable for Metro phone/
> tablet apps, and while it can run on Win64, it can't run as
> 64-bit. That means, for instance, that if you write an IE browser
> extension, Explorer Bar, etc., those can only be used in the 32
> bit version of IE and Explorer respectively. Over time those
> limitations may become notable. For the forseeable future,
> however, they're not relevant unless you want to target Metro.

Mayayana, you are a star,

Thanks for taking and interest and replying.

Currently my app is actually only targetting a couple of computers and
no need for Metro support. Its really just something that I'm working
on in my free time to help this family out, but it was difficult to
know where to begin.

Anyway cheers again.

L.

[toc] | [prev] | [next] | [standalone]

#1089

Sandwich <liam.whan@gmail.com> wrote:

>BTW you've convinced me to switch. I chose VB.net as I'm a new
>programmer and the temptation is to think that you might as well learn
>the most current imprint of the language.
>
>I'm writing this software for deloyment on workstations that are
>connected to a pretty tightly controlled Gov network, and when I tried
>to run a debug build .exe of my app on my workstation at work I got a
>dailog saying "you need to install .net redistributable packge
>4.xxxx", which worried me as I want this to useable on in as many
>environments as possible so it can be of assistance to staff who work
>with this lady in a variety of places (day programs, etc)
>
>So in short; I'm going to take your advice and switch languages! So
>can I confirm that VB6 would also be an appropriate choice?

Only if your client/employer has signed in blood that they have read
and understood this document
<http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx?ppud=4>.

Visual Basic "Classic" was probably the last in a line of BASIC
languages that made computer programming easy for beginners. I don't
think that it is a good language to teach yourself about programming
although it has the great advantage that you can produce a fancy GUI
with the minimum effort. In addition, given its doomed future, it
seems a waste of your time learning it now.

[toc] | [prev] | [next] | [standalone]

#1092

| Only if your client/employer has signed in blood that they have read
| and understood this document
| <http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx?ppud=4>.
|

  In blood? You must have some rather oddball clients.

  That page basically says what I already explained: VB6 software
 is widely supported, from Win95 through Win8, but the VB6 IDE as
a programming tool is no longer supported and won't be updated.
So newer aspects like 64-bit software are not possible with VB6.

   I've seen the argument put forth that Basic is poorly designed
and sets bad habits for programmers. It's debated periodically on
Slashdot. I still don't see exactly why that's the case. It's always
seemed to me more of a matter of personal taste and pros/cons
for a given job. The main point I see put forth is that VB allows
one to be sloppy. Then again, so does the blade guard on a table
saw. Surely the context of the job to be done has some bearing on
how to choose a tool? Maybe C for drivers, B for database front-ends,
and a blending in the spectrum in between?

   Either way, I'm curious what you would suggest for a simple
GUI program like that described. .Net has gigantic dependencies
and a questionable future. C++? That's an awfully lot of work, and
GUIs are tedious at best. And even that may have a shaky future.
Windows itself has a questionable future. One can use C++ to write
to Metro, but why go to so much trouble when you can only access
the WinRT wrapper sandbox? Since you're talking about a doomed
future, presumably you're talking about Win9 in .... 2016? What if
Win9 is Metro-only, and only MS software can run with the full API
(as will be the case with WinARM)? Should people then just stick to
javascript, on the assumption that it will be the lingua franca of a
cloud-crazed future where accessing an OS API will be a thing of
the past and the only widespread "programming" will be jazzed-up
webpages? (Personally I don't like javascript, but it *is* popping
up in an awfully lot of places.)

  Auric_ mentioned the many other current Basic options. Do you
consider all of them to be junk because of an inherent fault in
the design of Basic-style languages?

  I see no need to move from VB for many years to come, but if
I were just starting now the choices would be far less clear.
Windows programming is getting more restrictive. It's not clear
how useful custom compiled software will be in the future. MacOS
has always been restrictive. Linux will probably never be a suitable
Desktop OS. I don't even own a cellphone and have no plans to
buy one. Even if I did, having seen the shareware bubble come
and go, I'm not anxious to jump on the "phone app" bandwagon.
So for now I love VB and can do pretty much anything I need
with it, but it would be hard to recommend it as a first choice
to someone new.... except that I can't think of another first
choice that would be unquestionably better, at least for general
Windows "Desktop" software.

   I don't know if I really have a point here. You just raised a
couple of interesting issues; issues that are potentially transforming
with the arrival of Metro and WinARM.

| Visual Basic "Classic" was probably the last in a line of BASIC
| languages that made computer programming easy for beginners. I don't
| think that it is a good language to teach yourself about programming
| although it has the great advantage that you can produce a fancy GUI
| with the minimum effort. In addition, given its doomed future, it
| seems a waste of your time learning it now. 

[toc] | [prev] | [next] | [standalone]

#1093

Mayayana has brought this to us :
>> Only if your client/employer has signed in blood that they have read
>> and understood this document
>> <http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx?ppud=4>.
>> 
>
>   In blood? You must have some rather oddball clients.
>

<snip FUD, lies, and ignorant garbage />
>
>    I don't know if I really have a point here. You just raised a
> couple of interesting issues; issues that are potentially 
> transforming with the arrival of Metro and WinARM.
>


Joe, you are by far the biggest FUD machine I've ever seen.  Seriously, 
you should stick to writting bad vb code and hta's (lol!).  You really 
have no idea about anything.  C++ shaky future?  Seriously, that one 
comment proves you are clueless when it comes to technology.

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1094

| Joe, you are by far the biggest FUD machine I've ever seen.  Seriously,
| you should stick to writting bad vb code and hta's (lol!).  You really
| have no idea about anything.  C++ shaky future?  Seriously, that one
| comment proves you are clueless when it comes to technology.
|

  Nice to see your bile ducts are clear, Tom. I was
talking about C++ in terms of Windows programming.
On WinARM/Metro one can't write Windows software;
only WinRT applets. (Mozilla people were complaining
recently that MS isn't even going to let Firefox access
the Win32 API.) MS says you can use .Net, C++, or
javascript to write Metro applets.  At that point we're
essentially talking about using C++ to code sandboxed
HTAs. It wouldn't make much sense if the same thing
can be done with script, would it?

  So that's what I meant: Not that C++ has no future,
but rather that it's not clear how long we'll be able to
write and install compiled Windows software that uses
the full API. So C++ on Windows may become irrelevant.
(Remember C++/CLI? Did anyone ever use that? Now
there'll be C++/WinRT. It's rather insulting. It's like
car companies saying they'll no longer allow people to
work on their own cars...but feel free to use your power
socket wrench set when filling the windshield washer
fluid reservoir. It's one of the officially approved tools
for doing so. :) 

[toc] | [prev] | [next] | [standalone]

#1095

After serious thinking Mayayana wrote :
>> Joe, you are by far the biggest FUD machine I've ever seen.  
>> Seriously, you should stick to writting bad vb code and hta's 
>> (lol!).  You really have no idea about anything.  C++ shaky future?  
>> Seriously, that one comment proves you are clueless when it comes to 
>> technology.
>> 
>
>   Nice to see your bile ducts are clear, Tom. I was
> talking about C++ in terms of Windows programming.
> On WinARM/Metro one can't write Windows software;
> only WinRT applets. (Mozilla people were complaining
> recently that MS isn't even going to let Firefox access
> the Win32 API.) MS says you can use .Net, C++, or
> javascript to write Metro applets.  At that point we're
> essentially talking about using C++ to code sandboxed
> HTAs. It wouldn't make much sense if the same thing
> can be done with script, would it?


Seriously, learn something about technology before you speak.  Yes, 
there are some limitations in the initial cut of WinRT - but, most of 
those are for security reasons and user experience on low power 
devices.

Yes, there are some functionality gaps in the current WinRT api, but 
you can expect those to be closed over time.  In fact, I expect many 
will be closed by release.

If you for an instant think you can't write real apps for metro, you 
must not just be ignorant, but dumber than a post as well.

>   So that's what I meant: Not that C++ has no future,
> but rather that it's not clear how long we'll be able to
> write and install compiled Windows software that uses
> the full API. 

If you mean win32 - than my guess will be a long time.  Probably at 
least a few more versions - or when hardware is no longer able to run 
it.  But, not in metro.

> So C++ on Windows may become irrelevant.
> (Remember C++/CLI? Did anyone ever use that? 

In fact, yes.  I have used it on several occasions. Not for general app 
dev - but, I have used it to bring native code libraries into the .NET. 
 It's in fact very useful.

> Now
> there'll be C++/WinRT. It's rather insulting. It's like
> car companies saying they'll no longer allow people to
> work on their own cars...but feel free to use your power
> socket wrench set when filling the windshield washer
> fluid reservoir. It's one of the officially approved tools
> for doing so. :) 

Get this through your skull - as far as windows is concerned - the 
win32 api as you know it is deprecated.  It is there and maintained for 
backwards compatability.

As for your comments about C++/WinRT - huh?  You do realize, that you 
can use native code libraries in winrt?  You can't use the win32 api, 
but nothing stops you from creating your own...

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1098

| Get this through your skull - as far as windows is concerned - the
| win32 api as you know it is deprecated.  It is there and maintained for
| backwards compatability.
|

  That's simply not true. .Net is a wrapper around Win32.
WinRT is a wrapper around Win32.

http://tirania.org/blog/archive/2011/Sep-15.html
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx

  Win32 is not in any sense deprecated. It's restricted.
Read the news about Mozilla's complaints. They specifically
point out that IE (and other MS software) is using the
Windows API in Metro but that MS will not allow Firefox to
access it; and that they cannot produce a competitive browser
without that API access. Apparently the Mozilla people
thought MS would grant them an exception, but MS is no longer
under anti-trust scrutiny and they seem to have made clear
that there will be 2 classes of software going forward: The
native Microsoft programs (Office, IE, etc.) and everyone
else's sandboxed trinkets: WinRT HTAs. It's true, of course,
that WinRT is connected with battery issues, etc., but Metro
is also being put into Win8 as a wrapper GUI -- as the primary
GUI, even when there is no "swipe 'n smudge" functionality
on a given PC. And no one gets the option to choose which
native software they want to run. (Mozilla would presumably
write a lean version of Firefox for Metro and some people might
want the choice to risk their battery life. But they won't get
the choice.) Surely that's writing on the wall?

| As for your comments about C++/WinRT - huh?  You do realize, that you
| can use native code libraries in winrt?  You can't use the win32 api,
| but nothing stops you from creating your own...
|

   I don't see the logic there. Create my own what? My
own kernel? My own hardware interface APIs? I hope
you'll make that public if you produce such a thing. It
sounds like fun. :) 

[toc] | [prev] | [next] | [standalone]

#1099

Mayayana submitted this idea :
>> Get this through your skull - as far as windows is concerned - the
>> win32 api as you know it is deprecated.  It is there and maintained 
>> for backwards compatability.
>> 
>
>   That's simply not true. .Net is a wrapper around Win32.
> WinRT is a wrapper around Win32.
>

And?  Comming from a vb user, that is pretty hilarious that you would 
have issues with that.

> http://tirania.org/blog/archive/2011/Sep-15.html
> http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
>
>   Win32 is not in any sense deprecated. It's restricted.

Only on ARM - and MS is not encouraging it's use at all.  My point is 
that win32 is deprecated in that it is not likely to get a lot of 
further enhancement and that it's not going to be the official primary 
developement api for 3rd parties.

That's not to say it won't be around for a long time - of course it 
will.  But, that doesn't mean MS want's you to use it.  And so, in that 
sense it is deprecated.  Like VB6.  The runtime is still shiped - but, 
MS doesn't want you using it.

> Read the news about Mozilla's complaints. They specifically
> point out that IE (and other MS software) is using the
> Windows API in Metro but that MS will not allow Firefox to
> access it; 

The complaint is about the legacy desktop on arm - Windows RT.  MS is 
not allowing any 3rd party software to run there.  They are free to do 
so on x86.  And their Metro version will be allowed to run just fine.  
I'm not sure where Firefox would benifit from direct api access since - 
well, they don't use the same rendering engine that ie uses.  And there 
is nothing stoping them from accessing it.  In fact, they are already 
working on a metro version.

> and that they cannot produce a competitive browser
> without that API access.

Only on arm.  And why?  Firefox doesn't use the trident engine...  What 
else would they need that wouldn't be provided by winrt?

>  Apparently the Mozilla people
> thought MS would grant them an exception, but MS is no longer
> under anti-trust scrutiny and they seem to have made clear
> that there will be 2 classes of software going forward: The
> native Microsoft programs (Office, IE, etc.) and everyone
> else's sandboxed trinkets: WinRT HTAs. 

First off, metro apps are NOT trinkets - that kind of talk is what 
makes me think this conversation is pointless.  Sandboxed - yep.  It's 
called security.  But, that doesn't mean that apps can't communicate or 
interact.  It's just done differently (contracts).


> It's true, of course,
> that WinRT is connected with battery issues, etc., but Metro
> is also being put into Win8 as a wrapper GUI -- as the primary
> GUI, even when there is no "swipe 'n smudge" functionality
> on a given PC. And no one gets the option to choose which
> native software they want to run. (Mozilla would presumably
> write a lean version of Firefox for Metro and some people might
> want the choice to risk their battery life. But they won't get
> the choice.) Surely that's writing on the wall?
>


I think you are confusing Windows 8 and Windows RT (windows on arm).  
Windows 8 on x86 will allow them to have a native client - that you can 
download and install just like any other software.  You won't get it 
through the windows marketplace - that will be the metro version, but 
they can happily provide one for x86.  It's different on windows rt. MS 
is not allowing ANY 3rd party legacy desktop apps to run.

>> As for your comments about C++/WinRT - huh?  You do realize, that 
>> you can use native code libraries in winrt?  You can't use the win32 
>> api, but nothing stops you from creating your own...
>> 
>
>    I don't see the logic there. Create my own what? My
> own kernel? My own hardware interface APIs? I hope
> you'll make that public if you produce such a thing. It
> sounds like fun. :) 

Your own native code libraries, you know like mozilla's rendering 
engine, etd.

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1101

| >   Win32 is not in any sense deprecated. It's restricted.
|
| Only on ARM - and MS is not encouraging it's use at all.  My point is
| that win32 is deprecated in that it is not likely to get a lot of
| further enhancement and that it's not going to be the official primary
| developement api for 3rd parties.

  It is partially restricted on x86 Metro.
http://msdn.microsoft.com/en-us/library/windows/apps/br211369.aspx

   But I understand
what you mean. Nevertheless, this is an important point
that MS tries to cloud up. If you search for WinRT you'll find
all sorts of articles talking about how "the aging win32 api"
is being replaced by WinRT. There was similar talk when
.Net came out. In both cases the new wrapper is marketed
as a new core API, replacing Win32. Microsoft has successfully
misled people, in both cases, into thinking they're getting
a newer, better engine when actually they're just getting
a wrapper. Even the experts are confused. Dino Esposito
says here, quite plainly, that .Net runs on top of the Win32
API:
http://www.drdobbs.com/windows/232200577

But then he goes on in blurry, vague language to say strange things
about WinRT like: "Microsoft is attempting to touch and restructure
some of the pillars of all Windows applications", implying that WinRT
is a fundamental new core API.
   He then says, "WinRT is ultimately a new layer of code that is
expected to provide the same core services as Win32/COM."
A layer where? Again, he's implying but never actually claiming that
WinRT is a new core API. It sounds to me like he really just wasn't
sure when he wrote that article, so he avoided definitive statements.

  Yet one of Microsoft's own people says the following here:

http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx

"Moreover, the WinRT APIs call into the Win32 DLLs - so they
are not a replacement but rather a wrapper, an API flavor, on
top of Win32."

  So I'm not arguing with you on this. Just trying to clarify
what's going on and what the options are. Saying that Win32
is deprecated is misleading. What it really means is that MS
wants to discourage people from writing native software
and switch to web apps or phone apps. Deprecated generally
means "on its way out". The FONT tag was deprecated to let
people know that at some later point browsers wouldn't be
expected to support it. But MS is not phasing out Win32. And
Win32 is not "aging" or "crusty" or anything else of the sort.
Win32 is Windows. MS is just "discouraging its use" by anyone
other than themselves.

| > Read the news about Mozilla's complaints. They specifically
| > point out that IE (and other MS software) is using the
| > Windows API in Metro but that MS will not allow Firefox to
| > access it;
|
| The complaint is about the legacy desktop on arm - Windows RT.  MS is
| not allowing any 3rd party software to run there.  They are free to do
| so on x86.  And their Metro version will be allowed to run just fine.
| I'm not sure where Firefox would benifit from direct api access since -
| well, they don't use the same rendering engine that ie uses.

  How can you say that? MS software will have direct API
access on ARM while others will be limited to the WinRT
wrapper that prevents access to any direct hardware
and system APIs.

http://blog.mozilla.org/blog/2012/05/09/windows-on-arm-users-need-browser-choice-too/

  The author never explains exactly which functionality is
missing, but it seems like common sense to me. WinRT is a
sandboxing wrapper for software that's seems to be mainly
running in a browser window itself. (The GUI options are
CSS and XAML. I haven't seen a detailed explanation about
that, but that's why I was talking about HTAs. The entire
WinRT system seems to be a kind of browser-based web
services platform running on Windows.) How could a fullscale
browser be built on that? Even if WinRT were not so limited...
if it were equivalent to .Net or Java... that would still be a
step away from the efficiency of direct API.

|
| > It's true, of course,
| > that WinRT is connected with battery issues, etc., but Metro
| > is also being put into Win8 as a wrapper GUI -- as the primary
| > GUI, even when there is no "swipe 'n smudge" functionality
| > on a given PC. And no one gets the option to choose which
| > native software they want to run. (Mozilla would presumably
| > write a lean version of Firefox for Metro and some people might
| > want the choice to risk their battery life. But they won't get
| > the choice.) Surely that's writing on the wall?
| >
|
|
| I think you are confusing Windows 8 and Windows RT (windows on arm).
| Windows 8 on x86 will allow them to have a native client - that you can
| download and install just like any other software.  You won't get it
| through the windows marketplace - that will be the metro version, but
| they can happily provide one for x86.  It's different on windows rt. MS
| is not allowing ANY 3rd party legacy desktop apps to run.

  I understand all of that. But Metro on x86 is limited. (Link above.)
And it's the primary GUI. Native software can run on the Desktop.
I've already tested some and it's fine. But the Desktop, as you like
to say, is being "deprecated". The only reason to force Metro
on people with fullscale PCs is as a way to push toward further
restricting access in all versions of Windows down the road. On
a normal PC -- especially one without a touch-enabled screen --
there simply is no role at all for Metro. The M-Softies might say
that it's there because people mostly want to see realtime
updates onscreen, but that makes no sense. If you're on a bus,
looking at your phone, you might want to see who just posted
to your Facebook page without needing to log in. That's a clever
idea. But no one is going to sit around in their office, staring at
a 21" screen full of giant rectangles to watch Facebook news and
weather reports update themselves.

  This is what I was saying before: So far everything still works
as of Windows 8. The API is accessible. VB6 software runs. But
the writing is on the wall that Microsoft is probably going to
try to rein it all in down the road.

[toc] | [prev] | [next] | [standalone]

#1102

Mayayana was thinking very hard :
>>>   Win32 is not in any sense deprecated. It's restricted.
>> 
>> Only on ARM - and MS is not encouraging it's use at all.  My point 
>> is that win32 is deprecated in that it is not likely to get a lot of
>> further enhancement and that it's not going to be the official 
>> primary developement api for 3rd parties.
>
>   It is partially restricted on x86 Metro.
> http://msdn.microsoft.com/en-us/library/windows/apps/br211369.aspx
>
>    But I understand
> what you mean. Nevertheless, this is an important point
> that MS tries to cloud up. 

Nothing is clouding up.

> If you search for WinRT you'll find
> all sorts of articles talking about how "the aging win32 api"
> is being replaced by WinRT. 

Yep.  That is the plan, and more and more evidence is pointing that 
out.

> There was similar talk when
> .Net came out. 

And that was the plan, but it was premature.

> In both cases the new wrapper is marketed
> as a new core API, 

That was only briefly for .NET - for longhorn, before they "rebooted" 
the project.  That never saw the light of day, except in those few 
pre-alpha technology preview releases.

> replacing Win32. Microsoft has successfully
> misled people, in both cases, into thinking they're getting
> a newer, better engine when actually they're just getting
> a wrapper. 

I'm not even sure what your problem here is, no one is disputing that 
at least part of WinRT is a wrapper for a subset of the win32 api.  
Duh!  Why would they throw away code that has been around for ages?

I've never implied otherwise, jsut as some fo the win32 on 9x systems 
called into win16....

> Even the experts are confused. Dino Esposito
> says here, quite plainly, that .Net runs on top of the Win32
> API:
> http://www.drdobbs.com/windows/232200577
>
> But then he goes on in blurry, vague language to say strange things
> about WinRT like: "Microsoft is attempting to touch and restructure
> some of the pillars of all Windows applications", implying that WinRT
> is a fundamental new core API.

Yep.  That's the point.

>    He then says, "WinRT is ultimately a new layer of code that is
> expected to provide the same core services as Win32/COM."

Yep.

> A layer where? Again, he's implying but never actually claiming that
> WinRT is a new core API. 

It is.  It is the api that windows will be presenting in the future.  
Some features will continue to use the win32 underneath.  Some stuff 
will be implemented directly.  All of that is irrelavent to the point - 
win32 is not the primary api that is going to be targetd going forward.

> It sounds to me like he really just wasn't
> sure when he wrote that article, so he avoided definitive statements.
>
>   Yet one of Microsoft's own people says the following here:
>
> http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
>
> "Moreover, the WinRT APIs call into the Win32 DLLs - so they
> are not a replacement but rather a wrapper, an API flavor, on
> top of Win32."
>

Not sure what your point is.  They aren't going to dump the win32 - not 
for a bit.  That would be sucide - the facts are that windows 7 will be 
around for a long time.  Most big companies are just now transitioning 
to windows 7 from xp.  It will be at least 5 years before most of them 
even consider switching to windows 8 (the exception might be adoption 
of windows tablets).  So, win32 will be there, and so it makes sense 
that the new api, WinRT will make use of it when the functionality 
overlapps.  That's just smart software reuse....

>   So I'm not arguing with you on this. Just trying to clarify
> what's going on and what the options are. Saying that Win32
> is deprecated is misleading. What it really means is that MS
> wants to discourage people from writing native software

What does it have to do with native software?  Win32 is not the 
"native" windows api.  It's just one api profile that is available for 
the NT kernel.  The kernel api's are really the "native" api if you 
want to get down and dirty.  Just like SFU (services for unix) 
presented a unix api profile (which, called win32 for some of it's 
work).  That's all WinRT is is another api profile that happens to 
expose it self via com (which makes sense as well, that's what com is 
good at).  And WinRT at it's core is native compiled code.  So, please 
define what you mean by "native" in this context?

> and switch to web apps or phone apps. 

Not sure what you mean...  Metro apps will most likely run on either 
windows 8 or wp8 - but, not sure what web apps has to do with 
anything...

> Deprecated generally
> means "on its way out". 

And it is.  Just read a good summary of this over on the pb forums.  As 
noted, win32 api programmers are a dying breed.

> The FONT tag was deprecated to let
> people know that at some later point browsers wouldn't be
> expected to support it. But MS is not phasing out Win32. 

When it is no longer meant to be the primary development api for 
windws, I'm not sure what else it could mean...

> And
> Win32 is not "aging" or "crusty" or anything else of the sort.

LOL... Yes it is.

> Win32 is Windows.

Ah, taht's where your wrong.  Windows is the kernel. Windows is 
perfectly capable of prenting more than one api profile.  Win32 is just 
one of them.  Such as win64 and SFU are just a couple of examples.

>  MS is just "discouraging its use" by anyone
> other than themselves.
>

Yep.  They are tryign to present a more unified and modern api.  An api 
that can be used across multiple devices and platforms.  You know, the 
whole 3 screens thing...

And with the current trends in mobile, it makes sense.  The Win32 api 
is just not cut out for low power mobile devices.

>>> Read the news about Mozilla's complaints. They specifically
>>> point out that IE (and other MS software) is using the
>>> Windows API in Metro but that MS will not allow Firefox to
>>> access it;
>> 
>> The complaint is about the legacy desktop on arm - Windows RT.  MS 
>> is not allowing any 3rd party software to run there.  They are free 
>> to do so on x86.  And their Metro version will be allowed to run 
>> just fine. I'm not sure where Firefox would benifit from direct api 
>> access since - well, they don't use the same rendering engine that 
>> ie uses.
>
>   How can you say that? MS software will have direct API
> access on ARM while others will be limited to the WinRT
> wrapper that prevents access to any direct hardware
> and system APIs.
>

Isn't that what I just said?

> http://blog.mozilla.org/blog/2012/05/09/windows-on-arm-users-need-browser-choice-too/
>

That never mentions win32 at all.  Just no access to the Windows 
Classic Desktop.  This is not about win32 (well, not directly) but, 
access to the windows legacy desktop environment on ARM.

>   The author never explains exactly which functionality is
> missing, but it seems like common sense to me. 

Only because your lack knowledge.  You understand that google and 
mozilla are already making metro versions of their browsers right?  The 
metro version of firefox will run on x86 and arm, in the metro 
environment - but, you won't be able to run firfox in the legacy 
desktop on arm.

I would expect that in a version or two, ms will probably be removing 
that desktop environment completely from windows rt.

> WinRT is a
> sandboxing wrapper for software that's seems to be mainly
> running in a browser window itself.

Yes, ie 10 will be the primary rendering engine. sort of...

>  (The GUI options are
> CSS and XAML. I haven't seen a detailed explanation about
> that, but that's why I was talking about HTAs. The entire
> WinRT system seems to be a kind of browser-based web
> services platform running on Windows.) 

options:

html5+css+javascript
WPF+C#/VB.NET/C++

Which by the way, ie can already render xaml - as long as it doesn't 
have code behind.  On a high level XAML is simply a xml based 
discription of the UI.  It is compiled into a binary format, called 
baml, and then the runtime extracts that and uses it to render the UI 
on a directx drawing surface.  There are no "windows" in a pure wpf app 
(well, except the one containing the drawing surface). WPF is 
resolution independant.  WPF supports multi-touch and ink.  WPF is 
hardware accelerated (uses directx for the rendering).  And highly 
customizable.  It is was so good - that, the windows team has pulled it 
from the tools division and made it the primary api for metro apps.

> How could a fullscale
> browser be built on that? Even if WinRT were not so limited...

Because as I have told you many times already, Firefox does not use the 
native trident rendering engine.  It has it's own - gecko, a platform 
independant rendering engine.  It is already working on arm - under 
linux.  And, as I've already told you - you can create your own native 
code libraries and expose them to your Metro applications.

> if it were equivalent to .Net or Java... that would still be a
> step away from the efficiency of direct API.
>

You really don't understand anything do you?  You are just letting your 
assumptions cloud your oppinion.

>> 
>>> It's true, of course,
>>> that WinRT is connected with battery issues, etc., but Metro
>>> is also being put into Win8 as a wrapper GUI -- as the primary
>>> GUI, even when there is no "swipe 'n smudge" functionality
>>> on a given PC. And no one gets the option to choose which
>>> native software they want to run. (Mozilla would presumably
>>> write a lean version of Firefox for Metro and some people might
>>> want the choice to risk their battery life. But they won't get
>>> the choice.) Surely that's writing on the wall?
>>> 
>> 
>> 
>> I think you are confusing Windows 8 and Windows RT (windows on arm).
>> Windows 8 on x86 will allow them to have a native client - that you 
>> can download and install just like any other software.  You won't 
>> get it through the windows marketplace - that will be the metro 
>> version, but they can happily provide one for x86.  It's different 
>> on windows rt. MS is not allowing ANY 3rd party legacy desktop apps 
>> to run.
>
>   I understand all of that. But Metro on x86 is limited. (Link 
> above.) And it's the primary GUI.

yes, metro disallows direct win32 calls.  It can be done - but, you 
won't be able to get your apps in the app store if you plan to sell 
them :)

>  Native software can run on the 
> Desktop. 

The desktop you are refuring too is there for support of legacy apps :)

> I've already tested some and it's fine. But the Desktop, as 
> you like to say, is being "deprecated". The only reason to force 
> Metro on people with fullscale PCs is as a way to push toward further
> restricting access in all versions of Windows down the road. On
> a normal PC -- especially one without a touch-enabled screen --
> there simply is no role at all for Metro. The M-Softies might say
> that it's there because people mostly want to see realtime
> updates onscreen, but that makes no sense. If you're on a bus,
> looking at your phone, you might want to see who just posted
> to your Facebook page without needing to log in. That's a clever
> idea. But no one is going to sit around in their office, staring at
> a 21" screen full of giant rectangles to watch Facebook news and
> weather reports update themselves.
>

You realize what you said is completely ridiculous?  Of course no one 
is going to sit and stare the tiles - they will run apps.  See you keep 
thinking you can't create useful metro apps...  Which is not the case 
at all.

>   This is what I was saying before: So far everything still works
> as of Windows 8. The API is accessible. VB6 software runs. But
> the writing is on the wall that Microsoft is probably going to
> try to rein it all in down the road.

Yep.  But, it isn't all about control - it's about being able to create 
one app that runs accross multiple devices and hardware platforms.  
Obviously, they are changing a bit of the distribution model - and I 
can't blame them really.  It's about money, and apple seems to be doing 
quite a brisk buisness...  So, I'm not going to complain too much about 
that

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1104

    As usual, your "views" and "facts" are indistinguishable
from the Microsoft marketing party line, and this is beginning
to turn into one of those Lehrer Report discussions, where
two sides just vehemently blurt their pre-prepared propaganda,
with no clarification resulting.

   But I've said my piece and provided links, so anyone
concerned with where Windows and Windows programming
are headed can look into it themselves and come to their
own conclusions.

 

[toc] | [prev] | [next] | [standalone]

#1106

It happens that Mayayana formulated :
>     As usual, your "views" and "facts" are indistinguishable
> from the Microsoft marketing party line, and this is beginning
> to turn into one of those Lehrer Report discussions, where
> two sides just vehemently blurt their pre-prepared propaganda,
> with no clarification resulting.
>

LOL...  My views and facts are in line with reality.  The market is 
changing.  The desktop while still very important, is starting to slip 
from it's former position of glory.  Win32 is not compatible with that 
change.  There are 2 many different architectures and form factors.  MS 
is fighting for it's long term survival - well, I don't think 
ultimately the this change will cause the demise of MS, but they have 
certainly begun to slide down the totem poll of power :)  Fortunately, 
for them they have a lot of pieces in place to make said transition.  
The question is in my mind, will it be enough?

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1100

Mayayana laid this down on his screen :
>> Get this through your skull - as far as windows is concerned - the
>> win32 api as you know it is deprecated.  It is there and maintained 
>> for backwards compatability.
>> 
>
>   That's simply not true. .Net is a wrapper around Win32.
> WinRT is a wrapper around Win32.
>
> http://tirania.org/blog/archive/2011/Sep-15.html
> http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
>
>   Win32 is not in any sense deprecated.

Want more proof?  VS11 Express - no support for anything but metro 
apps...  You want to do windows forms or native api type stuff - you 
need to have a paid version.

-- 
Tom Shelton

[toc] | [prev] | [next] | [standalone]

#1121

 | Want more proof?  VS11 Express - no support for anything but metro
| apps...  You want to do windows forms or native api type stuff - you
| need to have a paid version.
|

  There's an interesting, clear article about this over
at Ars Technica today:

http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/

  Though I don't feel quite so gloomy about it all as the
Ars people do. VS6 was expensive. .Net and later versions
of C++ have been available in free versions up until now.
I have a free copy of VC++ 2008 that works fine. For
anyone starting out on Desktop software, the API hasn't
changed in a big way since 1995, so they don't need the
latest version.

  One point that hadn't been clear to me:
Even on x86, Metro software will only be available through
the MS online store, requiring fees and approval to get there
in the first place. Considering the differences with Metro, I
don't see any reason to lump that together with Windows
programming.

 There's Windows software.
 There's Metro trinkets on tablets and phones.

  The only real connection between the two is that Microsoft
has grafted a Metro GUI onto Windows, like some kind of bizarre,
superfluous Frankenstein head, as a marketing ploy to point
people toward their tablets and phones. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web