Specifications

The design question then turned from how to implement SMB on the player to how to

implement it on the PC. How does one write a Windows program that can open files

from its own local storage or remote location and in turn transfer the data into a buffer?

Very little was known about Windows programming and obviously a lot had to be

learnt.

After reading MSDN [22] about how to use SMB in Windows programming, it was

found that making direct calls to the SMB layer is not needed. If the programmer wants

to open local files they can open them directly and if they want to open a file from a

remote location the system redirector takes the command. Once the redirector sees that

the user wants a remote file it converts the information into SMB packets and performs

the operation. In most cases this redirector is the Client for Microsoft Networks Service

so this has to be installed in the computers networks settings for it to work. To access

these services a request for a file must be made in the universal naming convention. A

request for a file from a remote location must be made with the following syntax:

\\Servername\Sharename\Directory\Filename.

For a request to a file stored on the local file system it can be made as above but can

also be made as follows:

DriveLetter:\Directory\Filename.

For the Windows file handling APIs to be understand this structure where ever a ‘\’

occurs there needs to be two of them. This is so they are not confused for string

commands. The users can then very easily create, open, read or write files anywhere on

the computers local or remote file system. This was obviously a much simpler solution

then implementing SMB on the player it self.

The idea of having the interface directly to Windows implemented on the Ethernut was

good because it would make it autonomous. Ideally it would be more convenient to

allow the user to simply plug into any network without installing software on computers

and it would work. This sounded ideal but at this stage there was a physical problem,

the Ethernut didn’t seem to have enough resources to handle these extra functions and

there was not enough time to develop the protocol to find out if it did have enough

resources. The alternate solution the server was used.

The over design has then change to the operation shown in figure 9.