Perhaps <OT>: Visual Basic into MONO

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Perhaps <OT>: Visual Basic into MONO

Roger Oberholtzer
Perhaps this is off topic. Does anyone on this list have experience with
importing MS Visual Basic 6 code into MONO? I have been asked by an
engineer about getting it into MS .NET, and I suggested that since a
change was going to happen, why not explore MONO as well. Should I hide
behind my desk? I confess to having zip VB experience. I am a C/asm/Tcl
type.


--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int +46 8-615 60 20
Mobile: Int +46 70-815 1696

--

"On two occasions I have been asked (by members of Parliament!),
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able rightly to apprehend
the kind of confusion of ideas that could provoke such a question.
  - Charles Babbage 1791-1871)
    English computer pioneer, philosopher

And remember:

It is RSofT and there is always something under construction.
It is like talking about a large city with all construction finished.
Not impossible, but very unlikely.

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

PerfectReign
Roger Oberholtzer wrote:
> Perhaps this is off topic. Does anyone on this list have experience with
> importing MS Visual Basic 6 code into MONO? I have been asked by an
> engineer about getting it into MS .NET, and I suggested that since a
> change was going to happen, why not explore MONO as well. Should I hide
> behind my desk? I confess to having zip VB experience. I am a C/asm/Tcl
> type.
>
>
>  
If it is of any consolation - I remember still being at TechEd 2001
where Bill & Co. formally launched .NET. I was a VB programmer at the time.

Basically the word was - if your program is anything more than a
single-form with "hello world" running on a label, you'd be better off
recoding in .NET than trying to convert.

However - YMMV.

That said - I have tried running C# assemblies under mono and been
mildly successful. It only depended on the linked libraries and whether
or not the latest version of Windows.Forms was being used. (As usual,
the latest isn't supported in Mono.)


--
kai
www.perfectreign.com || www.filesite.org

a turn signal is a statement, not a request

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

Boyd Stephen Smith Jr.-3
In reply to this post by Roger Oberholtzer
On Thursday 2009 January 15 04:38:31 Roger Oberholtzer wrote:
>Perhaps this is off topic. Does anyone on this list have experience with
>importing MS Visual Basic 6 code into MONO? I have been asked by an
>engineer about getting it into MS .NET, and I suggested that since a
>change was going to happen, why not explore MONO as well. Should I hide
>behind my desk? I confess to having zip VB experience. I am a C/asm/Tcl
>type.

There was/is a migration tool available from MS to rewrite VB 6 code as
VB.Net.  Unfortunately, it's not very good.  If you run it against programs
of any complexity you either get code that won't compile (syntax error) OR
you get code that has many more bugs (runtime errors).

So, if you are going to move from VB 6 to VB.Net, it is a great time to move
to mono, clean up the code, and re-architect applications or whole
systems 'cause you are in for a complete re-write.  That's not a bad thing,
but does require significantly more resources than, e.g., the VB 5 to VB 6
move and you need to manage the project well enough to avoid Second System
Syndrome.
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

M Harris-2
On Thursday 15 January 2009 13:05, Boyd Stephen Smith Jr. wrote:
> There was/is a migration tool available from MS to rewrite VB 6 code as
> VB.Net.  Unfortunately, it's not very good.  If you run it against programs
> of any complexity you either get code that won't compile (syntax error) OR
> you get code that has many more bugs (runtime errors).
        geeze...  remember when "computer science" wasn't an oxymoron?






--
Kind regards,

M Harris     <><
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

Boyd Stephen Smith Jr.-3
On Sunday 18 January 2009, M Harris <[hidden email]> wrote
about 'Re: [opensuse] Perhaps <OT>: Visual Basic into MONO':
>On Thursday 15 January 2009 13:05, Boyd Stephen Smith Jr. wrote:
>> If you run it against
>> programs of any complexity you either get code that won't compile
>> (syntax error) OR you get code that has many more bugs (runtime
>> errors).
>
> geeze...  remember when "computer science" wasn't an oxymoron?

I don't believe it is.  Unfortunately, I've yet to deal with a company or
project that applied it to IT support or software development formally and
consistently.

Instead, we get XP and unit tests instead of correct code with known
failure cases.

It should be noted that, to the best of my knowledge, there is no BASIC
dialect with a behavior as well specified as the C or C++ standards.  
(Those leave a bit to be desired, too, but are probably the best we have.)
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

Roger Oberholtzer
On Sun, 2009-01-18 at 02:34 -0600, Boyd Stephen Smith Jr. wrote:

> On Sunday 18 January 2009, M Harris <[hidden email]> wrote
> about 'Re: [opensuse] Perhaps <OT>: Visual Basic into MONO':
> >On Thursday 15 January 2009 13:05, Boyd Stephen Smith Jr. wrote:
> >> If you run it against
> >> programs of any complexity you either get code that won't compile
> >> (syntax error) OR you get code that has many more bugs (runtime
> >> errors).
> >
> > geeze...  remember when "computer science" wasn't an oxymoron?
>
> I don't believe it is.  Unfortunately, I've yet to deal with a company or
> project that applied it to IT support or software development formally and
> consistently.
>
> Instead, we get XP and unit tests instead of correct code with known
> failure cases.
>
> It should be noted that, to the best of my knowledge, there is no BASIC
> dialect with a behavior as well specified as the C or C++ standards.  
> (Those leave a bit to be desired, too, but are probably the best we have.)

Of course. But in this case, it is MS and their own VBasic product. The
various dialects of VB must surely be understood by MS. Surely they know
the syntax and could import it into the .NET framework.

I am a bit confused by the real issues. VB code (any code, for that
matter), has two relevant properties in this context:

1) the language itself. Is it supported at the syntactic level?

2) system interface. (G)UI, hardware access (keyboards, mice, files)

So, does .NET allow things to be written in VB at all? I know that
languages like C# are preferred. But they are not mandatory. Are they? I
would have guessed that item 2 in the list above is the primary issue.
So if an application has separated the user interface from the
calculations ('pure language' calculations and no user/system I/O),
shouldn't it be 'easy' to get 'pure language' parts into .NET/MONO? As
always, the GUI is the trouble part.

Or are the issues different than this?

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int +46 8-615 60 20
Mobile: Int +46 70-815 1696

--

"On two occasions I have been asked (by members of Parliament!),
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able rightly to apprehend
the kind of confusion of ideas that could provoke such a question.
  - Charles Babbage 1791-1871)
    English computer pioneer, philosopher

And remember:

It is RSofT and there is always something under construction.
It is like talking about a large city with all construction finished.
Not impossible, but very unlikely.

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Perhaps <OT>: Visual Basic into MONO

Boyd Stephen Smith Jr.-3
On Monday 2009 January 19 02:20:54 Roger Oberholtzer wrote:
>On Sun, 2009-01-18 at 02:34 -0600, Boyd Stephen Smith Jr. wrote:
>> It should be noted that, to the best of my knowledge, there is no BASIC
>> dialect with a behavior as well specified as the C or C++ standards.
>> (Those leave a bit to be desired, too, but are probably the best we have.)
>
>Of course. But in this case, it is MS and their own VBasic product. The
>various dialects of VB must surely be understood by MS.

I disagree that they have to understand it.  The "correct" behavior of a piece
of VB 6 code is "whatever the MS VB 6 interpreter does".  That's difficult to
replicate completely in practice; it's hard enough to maintain during the
product lifecycle.  The "correct" behavior of a piece of VB 5 code
is "whatever the MS VB 5 interpreter does" -- even if this differs from what
the MS VB 6 interpreter does on the same code.

>Surely they know
>the syntax and could import it into the .NET framework.

Maybe, but they haven't shown enough interest in doing so.  Last I checked,
they recommended VB 6 (or before) shops move to VB.Net and provided the
aforementioned, buggy migration tool to help with some of the rewriting.

Also, being a .Net language means that all of your syntax needs to map to CLI
bytecode, instead of x86 machine code -- not necessarily the easiest
translation.

>I am a bit confused by the real issues. VB code (any code, for that
>matter), has two relevant properties in this context:
>
>1) the language itself. Is it supported at the syntactic level?

Each new version of VB is a slightly different language.  However, they are
traditionally similar enough in syntax that only a few constructs have to be
altered and sometimes this can be automated.  VB.Net is really a brand-new
language, with a syntax that, on the surface, feels familiar to VB 6 coders.  
That is, it looks like VB instead of looking like Java or C++.  However,
there is syntax that is valid in both VB 6 and VB.Net that has different
semantics.

In specific, MS's .Net development environment has support for VB.Net (aka "VB
7") at the syntactic level.  At this point, Mono does as well.

>2) system interface. (G)UI, hardware access (keyboards, mice, files)

This is unified across the .Net framework and standardized as the CLR.  It is
not language-specific when you discuss .Net languages.  VB.Net, C#, "Managed
C++", have equal access to these interfaces.  If you follow a few simple
rules when you are writing your libraries in any one of these languages, all
of the others can access them transparently, just like the CLR.

>So, does .NET allow things to be written in VB at all?

VB 6? No.
VB.Net? Yes.

>I know that
>languages like C# are preferred. But they are not mandatory. Are they?

No.  It is of course possible to design a .Net language that does not have a
syntax for accessing some CLI construct, possibly making some of the CLR
difficult to interact with, but such a language would be a "second-class
citizen" by design.  I don't think VB.Net is like this, but I've not written
much VB.Net code, and the code I was writing had no need to access
the "lower-level" or "lesser-used" areas of the CLR.

>I
>would have guessed that item 2 in the list above is the primary issue.

Oddly enough, not when you are talking about .Net languages.

>So if an application has separated the user interface from the
>calculations ('pure language' calculations and no user/system I/O),
>shouldn't it be 'easy' to get 'pure language' parts into .NET/MONO? As
>always, the GUI is the trouble part.

I'm not sure this is particularly relevant.  I think good separation of roles
makes the code easier to maintain and port.  But, if you want to run on the
CLR, you are going to have to move each and every part of program to a .Net
language anyway.
--
Boyd Stephen Smith Jr.                     ,= ,-_-. =.
[hidden email]                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'
http://iguanasuicide.net/                      \_/    

signature.asc (204 bytes) Download Attachment