Machine Code, VB & NES

No, it wouldn''t, VB uses the Win32 API to do everything.

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

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

Well, I meant the syntax. The LANGUAGE could be used, right?

lntakitopi@aol.com | http://www.geocities.com/guanajam

VB requires a lot of DLLs to accompany the application.

Also, VB only compiles to the x86 chips. The NES uses a different chip.

E:cb woof!

The language could only be used if you had a VB compiler specifically made for the NES chip.

E:cb woof!

In order to get it to work on the nes you would be stripping VB of a lot the things that seperate it from BASIC. Also wouldn''t it be some kind of copyright violation to make a new compiler for microsoft''s language?

Plus why would you want to spend time coding a VB compiler in asm or C? About half way through I would think you''d figure out the irony.

This is a strange/funny thread. Most of you don''t even know what VB looks like.

------------------------
Captured Reality

Well, then I guess it would be BASIC with an NES compiler, right? I''m not trying to have a heated argument, just a discussion...

lntakitopi@aol.com | http://www.geocities.com/guanajam

...while VB experts like nes are here, does VB have many syntactical differences from BASIC or is it just like Visual C++ (you just program in a more visual and Windows-based environment, but the language doesn''t change?) I would guess (with my limited experience) that it''s mostly normal BASIC with a Windows-based design & output.

lntakitopi@aol.com | http://www.geocities.com/guanajam

Many differences huh?

------------------------
Captured Reality

well, i would think that if your specialized compiler generated the nes code to draw all the windows and stuff, and removed the need for *.dll''s, it would be most definitely possible. i mean, just cuz you never saw menus and windows and stuff on the nes doesn''t mean it CAN''T happen, right? anyway, i don''t think shilbert is saying that he wants to make a windows app work on a nes, i mean, realistically, a windows program prob''ly wouldn''t fit on the cartridge (hehe) what i think he is saying is that, instead of having to write mov ax, 33; shr dx; whatever... he wants to be able to say VariableStoredInAX = 33: VarStoredInDX = VarStoredInDX * 4, or whatever.... and then the compiler would generate the code from that for the nes. the nes proggers probably had such a compiler to do that, not necessarily in vb, though, but i think you get the idea.

Sometimes even chickens need to eat... Don't bang your head against a wall just to enjoy the good feeling when you stop.

Why the hell would you want to make a compiler for the NES that uses VB in the first place???

------------------------
Captured Reality

quote:

---

you just program in a more visual and Windows-based environment

---

You drop the controls onto a form... At the very simplest level its a drag and drop interface. Then you handle the events (such as Button1_Click) with code. I spent about a year with VB, but being a megalomaniac, didn''t like it, as I didn''t know enough of what was going on below the interface... then of course the manual for VB is utterly boring... I''ve never tried DX with VB

J2xC (J. Connolly)

"Then study this: Borg provokes Klingon, Klingon breaks Borg's nose" Belanna Torres, Star Trek Voyager 5.11 "Someone to watch over me"

Well Now,

I was taught that every language or assembly
eventaully boils down to machine code at some
level. So I expect somewhere along the line
it would happen to VB. It Must happen to the
DLL''s you were talking about or the computer
might not understand. Of course I might be
wrong but It''s worth a try, thats what I think.
But yeh, why would anyone even consider making
VB compiler for the NES.

STVOY

Mega Moh Mine!!

Hi all.

Does''t VB genrate code of a larger foot print than other laguages? If so, that''s the last thing NES with it''s limited memory address (64K w/o bank switching). But may be N64 would more suitable for a VB *EQUIVALENT* compiler?

Some one saind what the diferences on VB, well it''s missing some statements:

swap
read/data/restore

May be new8bit can ilustrate us more about this.

Topgoro

I'll try to be as accurate as possible but I swear to god someone will flame me for this...

When you compile a VB project, you are creating COM objects whether you want them or not. Even if you are making all your code global and putting it all in .BAS modules, there is no way to disable or get rid of COM.

COM can be obscure and bizar, so VB makes all the COM stuff abstract to the programmer. So, to understand what VB is doing under the hood, you need to know why Microsoft's Component Object Modle is the way it is.

COM solves a huge number of problems with componetized software, especially those problems related to .DLLs. According to the MSDN documentation, the Windows "Clipboard" metaphore wasn't powerfull enough so Microsoft created DDE (Dynamic Data Exchange). DDE wasn't doing the job for Compound Document Linking (like draging a spread sheet into a word processor and wrapping text around it). So then Microsoft created OLE 1.0 which solved many problems but what Microsoft realized (again, I'm repeating what I read in MSDN documentation) is that OLE is a special case of a much more phenominal technology and thus came a better Modle for Componentizing software.

You guys are correct that VB compiles into native machine code. In fact, VC++ and VB compilers both have the same back end (the assembly/machine code generator ). And they both use the same linker.
COM modules (.DLLs, .EXEs, .OCXs) not only have the machine executible code in them, they also contain all the type information library and symbolics needed to generate the .TLI and the .TLH type library header files, as well as the numerated procedure addresses necessary for dynamic linking, as well as the Globally Unique Identifiers for registering the objects in the Windows registry.

Note that all .EXEs each run in there own separate address space. Also, the code can execute on a web server! So COM includes the technology for making remote procedure calls across process boundries and across network boundries. In my opinion, if you limit yourself to being only a VB programmer, Microsoft's VB documentation will keep you totally ignorant of these inter-process comunication technologies.

Before COM, there was little or no way to test the .DLL version when you were dynamically linking to 3rd party components. If a component vendor increments a version, software gets broken when the binanry image of a library changes (and the new .DLL overwrote the old .DLL). Alternatively, you could could use the Win32 API function LoadLibrary(), and then use GetProcAddress() for each function you are going to use, and store a pointer to that library function (I acually did this on a project and learned the hard way that it was a futile waste of my time and energy).

Anyone who uses COM in C++ knows that when you use the API in a library, you ask COM to create the object for you ( using CoCreateInstance() ) and then COM gives you a pointer to an interface. The interface is none other than a pure virtual class, it is a group of function pointers, and you are calling the API methods by double-indirection. I personally think it's easier to ask for a group of functions using CoCreateInstance(), than to ask for one function pointer at a time using GetProcAddress().

VB programmers know that every time they compile their projects, VB is generating new GUIDs, every time! On the contrary, there is a project setting you use to tell VB to "maintain binary compatiblility" with a previous build, but this only works if you never change your interfaces.

VB programmers also know that every time they create an object, each object can run on its own thread of execution. Actually each object is in its own "Apartment" such that if you compile your project to be single threaded, all apartments will share the same thread. In contrast, for multithreaded projects, if you create 10 objects then your .EXE will be running 10 threads of execution. Free-threading is only for C++ programmers.

Phew! This explanation goes on and on. But the gist of it is, you can't have Visual Basic on any platform other than Windows, unless you can reinvent the Wheel on COM. Without COM, you just don't have Visual Basic, all you have is plain BASIC.

As far as taking your VB code and porting it so you can compile for other platforms, you can forget it. Once my employer (stupid automakers) gave me a project to work on that involved upgrading some legacy code. They insisted I used Visual Basic and then they handed me a program written in Quick Basic thinking that I could just copy the legacy code and add the new features and everything would work out fine and dandy (Damn you, automakers, and your retarded *&$%!?!? futile &@*#(! asinine ##$#!! ...Ahem, well, I'm a little bitter.) Turns out, I was better off writting from scratch. You see, Quick Basic works with DOS, QB provides a single thread for your program. QB is procedureally oriented. VB provides an Object-Oriented-Event-Driven-Multithreaded-Blowjob9000 environment to BASIC programmers. That they are both named "Basic" doesn't imply compatibility or portablity anywhere, it only says that the languages have a grammer similar to the original BASIC language.

Now, can anyone flame me for the misleading information I gave? I had to have made a mistake somwhere. Maybe my only mistake is posting in this discussion in the first place.

"Do you bury me when I'm gone?
Do you teach me while I'm here?"
- James Hetfield


Edited by - Marsupial Rodentia on June 30, 2000 2:36:20 PM

Marsupial's right, I guess we should be arguing whether or not BASIC could be compiled to an NES program!

...Anyway, nes, I'm trying to show that some convoluted form of VB -- the language and syntax, anyway, not necessarily the inner workings and Windows parts -- could theoretically be compiled to run on an NES with a custom-made compiler. Why? Because someone said it was ironic that your namesake doesn't even use VB. I'm kind of defending you, in a way

Anyway, here's another question: Why do we call Visual Basic a language, but not Visual C++? It's obvious that the code compiled by MSVC doesn't differ from normal C++ in any way that could be called "visual." So why aren't people that use VB called BASIC programmers?

lntakitopi@aol.com / http://www.geocities.com/guanajam

Edited by - SHilbert on June 30, 2000 7:32:03 PM

Microsoft took BASIC and gave it a lot of the things it was missing (functions and OOP) and called it visual basic. It''s syntax is very different from BASIC''s (they ripped a lot from C++).

Visual C++ is mostly C++ with MFC and a better editor and debugger. It follows the ANSI standard on everything but some defines, and a few keywords like __int64.

Aaaah, it is all becoming clear...

lntakitopi@aol.com | http://www.geocities.com/guanajam

I seem to remember reading something in MSDN about how Visual C++ has a Microsoft variant. Like...some of the syntax and stuff that you can use in Visual C++ is not ANSI standard...it''s Microsoft additions to the language. You can still use the ANSI standard by specifying some option in one of the menus, although the Microsoft additions aren''t too bad. Anyhow, this is what I can remember...I don''t know if I''m right or not. And...the visual part of VC++ is stuff like the Resource Editors, and a couple things to help you manage MFC.

I know exactly what Visual Basic looks like. I spent some time a few years or so ago with Visual Basic 3.

P h a n t a s m
"I'd feel safer if the helicopter had an ejection seat."